サイジングの友。Exchange 2013 Server Role Requirements Calculatorが公開されています。

以前からExchange guysの間では使うのが常識になっているExchangeのサイジングツールですが、そのExchange Server 2013版が出ています。しかもメールボックスサーバーに限定されていない、全ロール向けのものになっています。助かりますね。 - Released: Exchange 2013 Server Role Requirements Calculator - Exchange Team Blog - Site Home - TechNet Blogs http://blogs.technet.com/b/exchange/archive/2013/05/14/released-exchange-2013-server-role-requirements-calculator.aspx サイジングは適当に行ってしまうと後で困るわけですが、きちんとやろうと思ってもアーキテクチャを理解していないと出来ない難しいものです。 例えばメールボックスを格納するディスクのサイズを計算しようと思っても単純にユーザーが使う領域を人数分掛け算すれば良いわけではなく、削除済みアイテムの領域も必要だし、削除されたメールボックスが完全に消されるまでの領域も必要だし、検索のためのインデックスを格納する領域も必要だし、トランザクションログ領域も必要だし、バックアップに失敗してトランザクションログがクリアされない時のための余裕も必要だし、DAGのメンバが長期間停止した時の考慮も必要だし……と、言い出したらきりもなければ抜け漏れも出やすいわけです。それが開発チームからガイドラインが出て、必要なパラメータを入れると参考値を出してくれるわけですから使わない手はないですね。 最もこれがあればあとは何もいらないわけでは全くありませんけれどもね。 リンクはリンク集にも追加しておきました。

May 30, 2013 · 1 min · 胡田昌彦

ファイルサーバーのデザインについてのあれこれ

ファイルサーバーのデザインについて質問を受けて、色々要素があって一応説明したけれどもあまり伝わらなかった気がするのでブログに書いておいてみます。 注意というか前提 何に関してもそうなのですが「どうするのがベストなのか?」という問いにはたいていの場合答えはありません。「いや、ベストってのはなかなかないよね。お客さんの使い方にあわせてベターな選択肢がいくつかあるという話であって、例外が無いなんていうことはあり得ないし…ごにょごにょ……」というのが本音であり、紳士的な回答だと思います。 #だいたい、何かにおいて「こたえはこれです!こうしておけば間違いない!」なんてのは騙そうとしているか、その人自身盲目になっちゃってるかですよね。 #怪しい宗教とか怪しいビジネスとか疑似科学なら断言するでしょうけどね! とはいえ、技術要素を抑えた上で「こうすればこうなる。一方こうすればこうなる。こういう前提ならこの選択肢がいいんじゃない?」ということは言えるし、お客さんの前では「お客様の環境や使い方を考慮すると、私としてはこのようなデザインと進め方をお勧めします。」ということはやっぱりプロとして言わなくちゃいけないですよね。それをするためには技術的なことを抑えた上でお客さんの希望や使い方を良く聞いて、自分の頭で考えてアイデアを出さなくちゃいけないです。 特にファイルサーバーのデザインや運用に関してははっきりいって「うまくいってる!」「こうすれば成功確実!」というようなものは聞いたことがありません。ファイルサーバーの権限管理は破綻し、ゴミファイルが散乱し、慢性的に容量不足で、組織変更の度にアクセス権設定とフォルダ構成変更とで多大な工数が必要となり…となってしまっている環境も多数あると思います。 そういう分野であるという認識の元、以下を読んでもらえればと思います。 抑えておくべき技術的な事 まず抑えておくべきは以下の事項です。 - [アクセス権の理解(NTFSアクセス権と共有アクセス権) - WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2009/04/15/%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e6%a8%a9%e3%81%ae%e7%90%86%e8%a7%a3ntfs%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e6%a8%a9%e3%81%a8%e5%85%b1%e6%9c%89%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e6%a8%a9/) - [コピー&ペーストとカット&ペーストではNTFSアクセス権が異なる - WindowsServer管理者への道](https://windowsadmin.ebisuda.net/2008/10/30/%e3%82%b3%e3%83%94%e3%83%bc%e3%83%9a%e3%83%bc%e3%82%b9%e3%83%88%e3%81%a8%e3%82%ab%e3%83%83%e3%83%88%e3%83%9a%e3%83%bc%e3%82%b9%e3%83%88%e3%81%a7%e3%81%afntfs%e3%82%a2%e3%82%af%e3%82%bb/) アクセス権の設定個所は「NTFSアクセス権」「共有のアクセス権」の2つがあるので(Windows Server 2012ではさらにもう1つ増えましたがここでは触れない事にします。すぐに使われそうも無いので。)どちらかあるいは両方のパターンについてきちんと検討が必要です。 NTFSアクセス権を使ってアクセス権をコントロールすることに決めた場合にはそのファイルをコピー、移動した時のアクセス権の動きに付いても考慮が必要です。 その他にも知っておいた方がよい事柄を紹介します。 NTFSのアクセス権を維持したままファイルをコピーする方法はある - NTFSのアクセス権はxcopy, robocopy等のコマンドでオプションを適切につければ、コピーであってもアクセス権を維持することができる。 これについてはヘルプを見てもらえば一発で分かるかと思います。xcopyなら/oオプション、robocopyなら/SECオプションあたりで実現できます。 フォルダがネストしていて、別階層が共有されている場合ユーザーが混乱するかもしれない - 共有フォルダの作成方法によっては「同一のファイルに複数のUNCパスが存在する」という状況が起きる。しかもその際に共有のアクセス権の設定方法によっては「ある人は複数のUNCパスで同一のファイルを開けるのに、別の人はこちらのパスでは開けるけれども、別のパスでは開けない」ということが起きる。 これについてはちょっと補足説明があった方がいいでしょうか。例えば以下のパスがあるとします。 - D:¥Share →Shareとして共有(¥¥Server¥Share, 管理者のみフルコントロール) - D:¥Share¥Share2 →Share2として共有(¥¥Server¥Share2, Everyoneフルコントロール) さてここでD:¥Share¥Share2¥folder¥file1.txtというファイルがあったとします。このファイルは1の共有からたどると 「¥¥Server¥Share¥Share2¥folder¥file1.txt」というUNCパスになります。一方2の共有からだと 「¥¥Server¥Share2¥folder¥file1.txt」というUNCパスになります。 管理者であればどちらのUNCパスからでも同じファイルにアクセスする事ができます。一方管理者以外の人は1の共有からのパスにはアクセスできません(共有のアクセス権を持たないので)。しかし、2の共有からのパスにはアクセスする事ができます。 エンドユーザーがこの事を理解して「あの人はこの共有にはアクセス権を持たないからこっちの共有からのUNCパスを伝えてあげないとな」と、気を利かせてくれたりする……ということはかなり難しいと思いますし、それを期待してはいけないと思います。 また、この場合でも、NTFSのアクセス権のみで制御し、共有のアクセス権はだれでも何でもできるような権限設定の場合にはアクセス自体には何も問題が発生しない事になります。ユーザーさんはちょっと混乱するかもしれませんけどね……。 組織毎にフォルダ作成、権限設定をすると組織変更時に泣きたくなる 決行スタンダードなファイルサーバーの設計として、「組織毎に管理する」というのはあると思います。組織毎にセキュリティグループがあり、ファイルサーバーにも組織毎のフォルダがあり、その組織に所属する人はその中にアクセスできる(つまり、組織のフォルダに組織のセキュリティグループでのアクセス権が設定してある。共有アクセス権か、NTFSアクセス権かはここでは問わない)。 一見なんの問題もなさそうな、スタンダードな設計に思えますが以下の場合には悲惨な事になります。 - 組織が頻繁に変わる 組織変更の度にファイルサーバーの中のファイルやフォルダを移動して回らないといけなくなります。1つの組織が2つに分割したら?どのフォルダ、ファイルがどちらの組織に所属すべきなのかを全部担当者に聞いて回らないといけない事になります…。 - 別の部署と共有したいファイルが出てくる 別の部署と共有したいばあい共有用に別の場所をつくってそこに移動してもらうか、その特定のファイル、フォルダだけアクセス権を変更してしまうか…というようなイレギュラーな対応をする必要が出てくると思います。別の場所に移動するとその場所のアクセス権の設定はどうしても緩くなり、そうするとそこの使い勝手がいい物だからみんなそこにファイルを作るようになり…と当初の構成が無意味になってしまう事が良くあります。 かといって特定のファイル、フォルダだけアクセス権を変更すると、都度管理者が特別対応をしなくてはいけないので管理者の負荷が上がる上に、出来上がった特別ファイル、フォルダは次の部署移動の際にどう扱っていいのか分からない事に……。 ユーザーにフルコントロールを与えてしまうとデザインを維持できない ユーザーが自分で好き勝手できるようにフルコントロールを与えてしまうケースがあります。そうするとそのユーザーはそのフォルダ以下すべて完全に好き勝手できちゃいます。アクセス権も変更できてしまうので、ある程度の枠組みを決めてあったとしても事実上破綻します。もちろんそのフォルダ以下は完全に権限移譲するのと引き換えに管理責任もきちんと引き取ってもらえるのならいいのかもしれません。…が、部署毎のフォルダ構造があるなかに勝手に別部署用のフォルダを作られたりなどもできちゃうのでやはりフルコントロールは危ないと思います。 アクセス権はグループでつけておき、ユーザーはグループへの追加、削除で権限管理するのが大抵うまくいく これはかなり常識的な感じですが、アクセス権のエントリに個人名を出してしまうのは良くない方法だと思います。 - 個人で付与すると、アクセス権を追加、削除したいときにすべての場所に個別に設定を行う必要が出てくる。 - 個人にしておくと、その個人アカウントを削除したときにアクセス権のゴミが残ってしまう。(生SIDが見えちゃうやつですね。) - 「XXさんの後任なので同じ権限で」と言われても、くまなく見て回って個別にアクセス権をつけるしか無くなってしまう。 このようになってしまうので、まず、グループを作成し、グループで権限をつけ、そのグループメンバの追加削除でアクセス権のコントロールをするとうまくいきます。 ...

August 30, 2012 · 1 min · 胡田昌彦