Nutanixは、ハイパーコンバージドインフラストラクチャーという、仮想化にとって最もシンプルで効率のよい、仮想化を最大限に使いやすくするインフラ基盤として誕生しました。
会社は2009年に生まれた会社で、日本でも知名度はだいぶ伸びてきましたが、 まだまだ変な会社とか、マンション経営の会社じゃないのとか、Nutanixという会社を知らない人にとっては、怪しいイメージを持っている人も居るかもしれません。
今日は、Nutanixの導入されている企業を紹介したいと思います。
この導入企業は、Nutanixサイトで公開されています。
まず、公共分野では、
があげられます。
どこも人口の多い都市であることは、見てすぐわかります。
こういった役所の重要な基盤は、Nutanixで稼働しています。
また、事例では公開されていませんが、日本中のかなり多くの市町村や府県でもNutanixの導入が進んでいます。
では次に医療分野を見てみましょう
がメーカー事例としてあげられています。
実は医療分野でもNutanixの導入はかなり進んでいるのですが、まだ出せる事例が少ないというのはあります。ただ、医療分野では電カル導入に伴うVDI導入も盛んですので、事例はどんどん増えるでしょう。
では次に金融を見てみましょう。
医療や金融はシステムの堅牢性や安定動作にかなり厳しい要求をしてきます。
ここで注目は、日本の株式を仕切る、東京証券取引所に導入されているということです。
これは、NutanixのWebスケールな分散の仕組みはこのような大規模でも威力を発揮すると言うことの表れです。言い換えれば、東証で動かせる高度な仕組みをNutanix3ノードで小さな企業でもその俊敏性と利便性が享受されるのは凄いことだと思います。
Nutanixにおいて重要なことは、できたてのスタートアップの企業が社内基盤に最小限のNutanixを導入して、その企業がどんどん成長して、東証に上場したとしても、ずっとNutanixを使い続けることができるのです。企業の成長に合わせてシステムを見直したり、リプレースする必要はありません。Nutanixは会社の成長に合わせて拡張ができます。ずっとその企業とつきあうことのできる基盤であることを是非知っておいてほしいです。
大企業のためNutanixでもなく、中小零細企業のためのNutanixでもなく、どんな企業にもフィットする仮想化基盤がNutanixなのです。
Nutanixの事例はこちらから参照することができます。
2017年9月27日水曜日
2017年9月26日火曜日
AFS(Acropolis File Service)を使ってみよう その６
Acroplis File Service(AFS)が、ファイルサーバーんの機能として十分な機能を持っているということと、必要に応じてむ停止で容量の拡張ができる点や、OneClickUpgradeによる無停止の機能拡張ができるというメリットは、今までの検証でよくわかってきました。
今回は機能ではなく、メンテナンス時のAFSの起動と終了方法について抑えていきたいと思います。
AFSは、無停止でソフトウェアアップグレード（OneClick Upgrade）ができる点や、容量拡張も無停止でできる側面から、AFSを止めてメンテナンスをするということは、まずないといえるでしょう。
ただ、社内の電源設備点検や、移設作業など、なんらかの理由によってNutanixクラスターを停止させる場合、あらかじめAFSのサービスを安全に停止した上で、Nutanixクラスターの停止を行う必要があります。
AFSのシャットダウンは簡単です。
以上で終了です。
とても簡単で、かつ、各FSVMをすべてシャットダウンしてくれるのは大変便利です。
シャットダウンはFSVMの数により異なりますが、今回の検証環境では、3台のFSVMで、だいたい3分程度でシャットダウンがで完了しました。
では、起動はというとこちらも簡単で以下の手順で行います。
こちらの起動も3台のFSVM環境で、約1分程度で起動が完了しました。
もちろん、起動完了後は、\\afs01で普通にアクセス可能となります。
▼menrva -a startコマンド実行後、3分程度でファイルサーバーにアクセス可能
シャットダウンコマンドと起動コマンドは、CVMから発行することと、コマンド自体（minerva）も忘れずに覚えておきましょう。
起動コマンド
シャットダウンコマンド
これで、急なメンテナンスや停電によるUPSシャットダウンにも安心して対応が可能です。
今回は機能ではなく、メンテナンス時のAFSの起動と終了方法について抑えていきたいと思います。
AFSは、無停止でソフトウェアアップグレード（OneClick Upgrade）ができる点や、容量拡張も無停止でできる側面から、AFSを止めてメンテナンスをするということは、まずないといえるでしょう。
ただ、社内の電源設備点検や、移設作業など、なんらかの理由によってNutanixクラスターを停止させる場合、あらかじめAFSのサービスを安全に停止した上で、Nutanixクラスターの停止を行う必要があります。
AFSのシャットダウンは簡単です。
- 任意のCVMにSSHでログインします。
- 「minerva -a stop」コマンドを入力します
- 自動的にAFSのサービスが終了し、AFSのFSVMがシャットダウンされ、パワーオフ状態になります。
以上で終了です。
とても簡単で、かつ、各FSVMをすべてシャットダウンしてくれるのは大変便利です。
シャットダウンはFSVMの数により異なりますが、今回の検証環境では、3台のFSVMで、だいたい3分程度でシャットダウンがで完了しました。
では、起動はというとこちらも簡単で以下の手順で行います。
- 任意のCVMにSSHでログインする
- 「minerva -a start」
- 自動的にFSVMが起動し、AFSサービスが起動する
こちらの起動も3台のFSVM環境で、約1分程度で起動が完了しました。
もちろん、起動完了後は、\\afs01で普通にアクセス可能となります。
▼menrva -a startコマンド実行後、3分程度でファイルサーバーにアクセス可能
シャットダウンコマンドと起動コマンドは、CVMから発行することと、コマンド自体（minerva）も忘れずに覚えておきましょう。
起動コマンド
nutanix@NTNX-HVXXXX-A-CVM:192.168.XX.XX:~$ minerva -a stop
シャットダウンコマンド
nutanix@NTNX-HVXXXX-A-CVM:192.168.XX.XX:~$ minerva -a start
これで、急なメンテナンスや停電によるUPSシャットダウンにも安心して対応が可能です。
2017年9月25日月曜日
AFS(Acropolis File Service)を使ってみよう その５
AFSがファイルサーバーとして実装されている一通りの機能を見てきました。
ファイルサーバーを運用するにあったて課題事項になるのが、ユーザー側の操作ミスによるファイルの誤った上書きや削除なのです。
この場合、管理者にお願いをしてファイルをリストアしてもらう必要が出てきますが、利用するユーザーが多いとこれもまたシステム管理者の負荷を上げてしまうことになります。
そこで利用するのが、Self Service Restore(SSR)機能です。
前回の項で、「DivisionShare」フォルダは、SSRを有効にしましたので、この内容は一応おさらいとしましょう。
▼SSRの有効を確認
では、実際にSSR機能を使ったファイルリストアを行ってみたいと思います。
今回は「shizuka」アカウントで、大事な焼き芋データーベースである「imo.mdb」を誤って削除したという想定で行います。
まずは、「静香の焼き芋データーベース」フォルダを右クリックし、「プロパティ」を開きます。
▼リストアしたファイルが配置されるディレクトリのプロパティを開く
プロパティウィンドウから、「以前のバージョン」を開きます。
すると、AFSで定期的にバックアップがとられている履歴のディレクトリが表示されます。
開いたディレクトリは、そのバックアップが取得された時点のファイルが表示されますのでその ファイルを本来のAFSのディレクトリにコピーを取ればリストアは完了です。
▼ファイルの復元で表示されたファイルと実際のAFS01のディレクトリ
さて、このバックアップはいったいどのようにだれがとっているのでしょうか？
これは、AFS展開時に自動的にDataProtectionの設定が行われています。
PrismのFileServer画面から、「Protect」メニューをクリックします。
Protect画面を確認すると、1時間に1回が24世代、1日に1回が7世代といった方のジョブが自動的に生成されています。
このジョブによって、自動的にファイルが守られており、必要に応じてファイルの復元で戻すことができるということです。
スケジュールや世代数は、変更がこの画面から可能ですので、自分で好きな世代数にすることも可能です。
ここまで、ファイルサーバーの構築から運用までを見てきましたが、AFSにはファイルサーバーとして必要十分な機能が搭載されていることがわかりました。
ファイルサーバーを運用するにあったて課題事項になるのが、ユーザー側の操作ミスによるファイルの誤った上書きや削除なのです。
この場合、管理者にお願いをしてファイルをリストアしてもらう必要が出てきますが、利用するユーザーが多いとこれもまたシステム管理者の負荷を上げてしまうことになります。
そこで利用するのが、Self Service Restore(SSR)機能です。
前回の項で、「DivisionShare」フォルダは、SSRを有効にしましたので、この内容は一応おさらいとしましょう。
▼SSRの有効を確認
では、実際にSSR機能を使ったファイルリストアを行ってみたいと思います。
今回は「shizuka」アカウントで、大事な焼き芋データーベースである「imo.mdb」を誤って削除したという想定で行います。
まずは、「静香の焼き芋データーベース」フォルダを右クリックし、「プロパティ」を開きます。
▼リストアしたファイルが配置されるディレクトリのプロパティを開く
プロパティウィンドウから、「以前のバージョン」を開きます。
すると、AFSで定期的にバックアップがとられている履歴のディレクトリが表示されます。
開いたディレクトリは、そのバックアップが取得された時点のファイルが表示されますのでその ファイルを本来のAFSのディレクトリにコピーを取ればリストアは完了です。
▼ファイルの復元で表示されたファイルと実際のAFS01のディレクトリ
さて、このバックアップはいったいどのようにだれがとっているのでしょうか？
これは、AFS展開時に自動的にDataProtectionの設定が行われています。
PrismのFileServer画面から、「Protect」メニューをクリックします。
Protect画面を確認すると、1時間に1回が24世代、1日に1回が7世代といった方のジョブが自動的に生成されています。
このジョブによって、自動的にファイルが守られており、必要に応じてファイルの復元で戻すことができるということです。
スケジュールや世代数は、変更がこの画面から可能ですので、自分で好きな世代数にすることも可能です。
ここまで、ファイルサーバーの構築から運用までを見てきましたが、AFSにはファイルサーバーとして必要十分な機能が搭載されていることがわかりました。
2017年9月24日日曜日
AFS(Acropolis File Service)を使ってみよう その４
前回までに、共有フォルダに対してより細かい権限設定ができることがわかりました。
しかし、ユーザー権限を付与するごとに共有フォルダを作成すると、共有フォルダだらけになり、一般的によく起きゆるファイルサーバーの無法地帯化の一歩に近づいてしまっている気がします。
そのため、共有フォルダを1つ作成しその中のサブフォルダで細かい権限を設定し、共有フォルダの数を減らしつつ、セキュアな環境を作成したいと思います。
まず、Prism画面で、前回までに作成したDivisionShareの設定変更を行います。
FileServerの項で、「DivisionShare」選択し、Updateをクリックします。
オプションとして、「Enable Access Based Enumeration(ABE)」と「Self Service Restore」にチェックを入れ、Saveをクリックします。
では、この状態で２つのフォルダを作成し、権限付与をしたいと思います。
「\\afs01\DivisionShare」の配下に以下のフォルダを作成します。
「のび太の100点テストPDF」フォルダ
こちらは、権限設定で管理者とのび太くんのみが見えるように設定します。
ここで必要になることは、このフォルダはDivisionShareの配下にあるフォルダのため、前フォルダの権限情報を継承しています。
そのため、DivisionShareフォルダは以下に、管理者権限でWindowsPCから、フォルダ「のび太の100点テストPDF」を作成し、プロパティを開きます。
セキュリティタブから「詳細設定ボタン」をクリックします。
このフォルダは、その権限を継承しないため、継承の無効化をクリックします。
その後許可ユーザーを制限し、OKをクリックし反映させます。
同様の要領で、 「静香の焼き芋データーベース」も作成し、静香ちゃんとシステム管理者だけがアクセスできる権限を付与します。
▼管理者から見た「\\afs01\DivisionShare」を確認しておきましょう。
では、実際にクライアントからアクセスしてみましょう。
まずは、suneoアカウントでログインをし、「\\afs01\divisionshare」配下を見てみます。
▼suneoアカウントから見た「\\afs01\divisionshare」配下
▼nobitaアカウントから見てみましょう。
のび太くんからは、静香ちゃんの焼き芋データーベースフォルダは表示されていません。
では、shizukaアカウントから見てみましょう。
このように、共有フォルダ配下にフォルダを作成し、個別の権限を設定した場合、Enable Access Based Enumeration(ABE)機能が有効になり、必要のないフォルダが表示から除外されます。
では、Prism上から「DivisionShare」のABE機能をオフにしてみましょう。
それで、もう一度shizukaユーザーから、「\\afs01\DivisionShare」を見てみましょう。
すると、先ほどと異なりすべてのフォルダが見えることがわかります。
ここでは、静香ちゃんがアクセス許可されていない、「のび太の100点テストPDF」フォルダを開いてみましょう。
▼shizukaユーザーからアクセス権限のないフォルダをアクセスしたところ
ABEをオフにするとすべてのフォルダが見えてしまいますので、セキュアな環境を作成するという観点から考えると、ABEの機能は有効にしておいたほうがメリットがあるように思います。
また、従来のSamba2.xのように、サブフォルダに別の権限が付与できないといったこともありませんし、ABEを利用することで、従来の単体のWindowsサーバーでは難しかったフォルダを必要に応じて隠すこともできます。
ファイルサーバーとして利用するには必要十分な機能が実装されていることが今回わかりました。
次回は、ファイルリストアの機能を確認してみたいと思います。
しかし、ユーザー権限を付与するごとに共有フォルダを作成すると、共有フォルダだらけになり、一般的によく起きゆるファイルサーバーの無法地帯化の一歩に近づいてしまっている気がします。
そのため、共有フォルダを1つ作成しその中のサブフォルダで細かい権限を設定し、共有フォルダの数を減らしつつ、セキュアな環境を作成したいと思います。
まず、Prism画面で、前回までに作成したDivisionShareの設定変更を行います。
FileServerの項で、「DivisionShare」選択し、Updateをクリックします。
オプションとして、「Enable Access Based Enumeration(ABE)」と「Self Service Restore」にチェックを入れ、Saveをクリックします。
では、この状態で２つのフォルダを作成し、権限付与をしたいと思います。
「\\afs01\DivisionShare」の配下に以下のフォルダを作成します。
「のび太の100点テストPDF」フォルダ
こちらは、権限設定で管理者とのび太くんのみが見えるように設定します。
ここで必要になることは、このフォルダはDivisionShareの配下にあるフォルダのため、前フォルダの権限情報を継承しています。
そのため、DivisionShareフォルダは以下に、管理者権限でWindowsPCから、フォルダ「のび太の100点テストPDF」を作成し、プロパティを開きます。
セキュリティタブから「詳細設定ボタン」をクリックします。
このフォルダは、その権限を継承しないため、継承の無効化をクリックします。
その後許可ユーザーを制限し、OKをクリックし反映させます。
同様の要領で、 「静香の焼き芋データーベース」も作成し、静香ちゃんとシステム管理者だけがアクセスできる権限を付与します。
▼管理者から見た「\\afs01\DivisionShare」を確認しておきましょう。
では、実際にクライアントからアクセスしてみましょう。
まずは、suneoアカウントでログインをし、「\\afs01\divisionshare」配下を見てみます。
▼suneoアカウントから見た「\\afs01\divisionshare」配下
▼nobitaアカウントから見てみましょう。
のび太くんからは、静香ちゃんの焼き芋データーベースフォルダは表示されていません。
では、shizukaアカウントから見てみましょう。
このように、共有フォルダ配下にフォルダを作成し、個別の権限を設定した場合、Enable Access Based Enumeration(ABE)機能が有効になり、必要のないフォルダが表示から除外されます。
では、Prism上から「DivisionShare」のABE機能をオフにしてみましょう。
それで、もう一度shizukaユーザーから、「\\afs01\DivisionShare」を見てみましょう。
すると、先ほどと異なりすべてのフォルダが見えることがわかります。
ここでは、静香ちゃんがアクセス許可されていない、「のび太の100点テストPDF」フォルダを開いてみましょう。
▼shizukaユーザーからアクセス権限のないフォルダをアクセスしたところ
ABEをオフにするとすべてのフォルダが見えてしまいますので、セキュアな環境を作成するという観点から考えると、ABEの機能は有効にしておいたほうがメリットがあるように思います。
また、従来のSamba2.xのように、サブフォルダに別の権限が付与できないといったこともありませんし、ABEを利用することで、従来の単体のWindowsサーバーでは難しかったフォルダを必要に応じて隠すこともできます。
ファイルサーバーとして利用するには必要十分な機能が実装されていることが今回わかりました。
次回は、ファイルリストアの機能を確認してみたいと思います。
2017年9月23日土曜日
AFS(Acropolis File Service)を使ってみよう その３
前回はQuotaに対する動作を確認しました。
では、次に権限設定を確認してみましょう。
今回は、DivisionShareという共有ディレクトリを作成し、以下のような権限を設定したいともいます。
※アカウントがみんな名前なのに出木杉君だけ、苗字なのはご愛嬌ということで...。
▼DivisionShareディレクトリの設定
では、次に共有フォルダ地震に対する権限設定を行います。
これは、Prism画面からではできません。
管理者権限（Administrator)権限でログインしたWindowsPCにログインし、コンピューターの管理を開きます。（画面はWindows10 x64 1703にて作業を行います）
まずは、PCで、コンピューターの管理を開きます。
コンピューターの管理を開くと、「別のコンピューターへ接続」をクリックします。
接続するサーバーはafs01になりますので、「\\afs01」と入力し、OKをクリックします。
接続が完了したら、コンピューターの管理（AFS01)となっていることを確認します。
続いて、システムツールのツリーを開きます。
AFSは純粋はWindowsサーバー派ではないため、COM+とリモートイベントの取得に失敗した旨のメッセージが表示されますが、OKをクリックし継続します。
続いて共有フォルダツリーを開き、「共有フォルダ」から「共有」を開き、AFSで作成した「DivisionShare」フォルダを右クリックし、プロパティを開きます。
続いてアクセス権を確認します。
デフォルトでは、Everyoneになっています。
そのため、共有フォルダを作成したら、だれでもフルコントロールでアクセスできるというのがわかりました。これはセキュリティ的にもよくありませんので、最初に定義をしたユーザーのアクセス権の追加を行い、剛田武だけを権限を入れない形で設定をします。
なお、ユーザーのみに権限を与えると、Administrators権限ユーザーが管理できなくなってしまいますので、AdministratorsとAdministratorもフルコントロールを入れておくことも忘れずに行います。
▼出木杉くんは読み取り専用
▼のび太はフルコントロール
設定が終わるとこれでOKをクリックします。
さて、Windowsクライアントから実際のアクセスを試してみたいと思います。
まずは、権限が付与されていない剛田武のアカウントで\\afs01を開いてみたいと思います。
共有フォルダである「DivisionShare」が表示されていることがわかります。
このディレクトリをダブルクリックすると、アカウント情報の入力が求められます。
この操作しているPCは、AFS01も参加している「toriten.oita」ドメインに参加しており、takeshiカウアントでログインしているので、AD認証情報は持っているはずなのですが、それでも認証情報を聞いてくるというのがポイントです。
OSログインのユーザーでは、このフォルダにアクセスができないことがわかります。
▼takeshiアカウントでは、DivisionShareディレクトリを開こうとしてもアカウント情報を求められる
では、一方でのび太アカウントでも確認をしてみましょう。
のび太はファイルの作成やディレクトリの作成もすんなりできていることがわかります。
これで、権限設定が正しく割り当たっていることがわかりました。
では、最後に読み取り専用の出木杉くんアカウントで見てみましょう。
ディレクトリの閲覧やファイルのオープンも可能ですが、出木杉君自身がファイルを作成しようとすると、アクセス権が拒否されたとの画面が表示されました。
これも想定通りですね。
のび太君が作成したファイルに上書きをしようとするもこれも拒否されました。
明確に、出木杉君は読み取り専用アクセスがついていることがわかります。
これで、ユーザー権限が正しく反映されていることがわかりました。
次回は、より深い権限についてみていきたいと思います。
では、次に権限設定を確認してみましょう。
今回は、DivisionShareという共有ディレクトリを作成し、以下のような権限を設定したいともいます。
▼DivisionShareディレクトリの設定
では、次に共有フォルダ地震に対する権限設定を行います。
これは、Prism画面からではできません。
管理者権限（Administrator)権限でログインしたWindowsPCにログインし、コンピューターの管理を開きます。（画面はWindows10 x64 1703にて作業を行います）
まずは、PCで、コンピューターの管理を開きます。
コンピューターの管理を開くと、「別のコンピューターへ接続」をクリックします。
接続するサーバーはafs01になりますので、「\\afs01」と入力し、OKをクリックします。
接続が完了したら、コンピューターの管理（AFS01)となっていることを確認します。
続いて、システムツールのツリーを開きます。
AFSは純粋はWindowsサーバー派ではないため、COM+とリモートイベントの取得に失敗した旨のメッセージが表示されますが、OKをクリックし継続します。
続いて共有フォルダツリーを開き、「共有フォルダ」から「共有」を開き、AFSで作成した「DivisionShare」フォルダを右クリックし、プロパティを開きます。
続いてアクセス権を確認します。
デフォルトでは、Everyoneになっています。
そのため、共有フォルダを作成したら、だれでもフルコントロールでアクセスできるというのがわかりました。これはセキュリティ的にもよくありませんので、最初に定義をしたユーザーのアクセス権の追加を行い、剛田武だけを権限を入れない形で設定をします。
なお、ユーザーのみに権限を与えると、Administrators権限ユーザーが管理できなくなってしまいますので、AdministratorsとAdministratorもフルコントロールを入れておくことも忘れずに行います。
▼出木杉くんは読み取り専用
▼のび太はフルコントロール
設定が終わるとこれでOKをクリックします。
さて、Windowsクライアントから実際のアクセスを試してみたいと思います。
まずは、権限が付与されていない剛田武のアカウントで\\afs01を開いてみたいと思います。
共有フォルダである「DivisionShare」が表示されていることがわかります。
このディレクトリをダブルクリックすると、アカウント情報の入力が求められます。
この操作しているPCは、AFS01も参加している「toriten.oita」ドメインに参加しており、takeshiカウアントでログインしているので、AD認証情報は持っているはずなのですが、それでも認証情報を聞いてくるというのがポイントです。
OSログインのユーザーでは、このフォルダにアクセスができないことがわかります。
▼takeshiアカウントでは、DivisionShareディレクトリを開こうとしてもアカウント情報を求められる
では、一方でのび太アカウントでも確認をしてみましょう。
のび太はファイルの作成やディレクトリの作成もすんなりできていることがわかります。
これで、権限設定が正しく割り当たっていることがわかりました。
では、最後に読み取り専用の出木杉くんアカウントで見てみましょう。
ディレクトリの閲覧やファイルのオープンも可能ですが、出木杉君自身がファイルを作成しようとすると、アクセス権が拒否されたとの画面が表示されました。
これも想定通りですね。
のび太君が作成したファイルに上書きをしようとするもこれも拒否されました。
明確に、出木杉君は読み取り専用アクセスがついていることがわかります。
これで、ユーザー権限が正しく反映されていることがわかりました。
次回は、より深い権限についてみていきたいと思います。
2017年9月22日金曜日
AFS(Acropolis File Service)を使ってみよう その２
前回までにQuotaの細かい設定を確認しました。
では、具体的に細かな設定を入れてみて動作を試したいと思います。
共有名：AllShare
MAS SHARE SIZE(全体サイズ制限)：20GiB
の状態で設定を行います。
次に、ユーザー別のQuota設定を行います。
Quotaには、以下のような設定を施します。
nobita@toriten.oita -> 10GiBの容量制限 / SoftLimit
suneo@toriten.oita -> 1GiBの容量制限 / HardLimit
また、通知用のメールアドレスも設定をしておきたいと思います。
▼suneoに対する制限の画面
ユーザーごとに設定したQuota設定状態は、Prismの画面から確認可能ですし、そこから編集が可能です。
では、nobitaユーザーから、CentOS7.3と7.4の2つのISOファイルをコピーしてどうなるかを確認してみましょう。
nobitaユーザーはソフトリミットの5TiBでしたので、今回合計で8.29GB程度のファイルでしたが、問題なくコピーができました。
一方ソフトリミットとはいえ、ポリシーを違反したコピーが行われていますので、管理者には以下のような形でアラートのメールが届いています。
一歩で、ユーザー、suneoは、ファイルコピーが1GiBで制限されるかを確認してみましょう。
suneoは、Redhat Enterprise Linux 7.4のISO(3.78GB)をコピーしてみましょう。
ちなみにsuneoの場合、いきなり容量超過したファイルをコピーしようとしてファイルサーバー(AFS)から拒否されているので、この場合、通知のメールは管理者には送られません。
これで、ユーザーごとにQuotaの動作が正常に行われていることがわかります。
次回はアクセス権限とABEについて紹介をしたいと思います。
では、具体的に細かな設定を入れてみて動作を試したいと思います。
共有名：AllShare
MAS SHARE SIZE(全体サイズ制限)：20GiB
の状態で設定を行います。
次に、ユーザー別のQuota設定を行います。
Quotaには、以下のような設定を施します。
nobita@toriten.oita -> 10GiBの容量制限 / SoftLimit
suneo@toriten.oita -> 1GiBの容量制限 / HardLimit
また、通知用のメールアドレスも設定をしておきたいと思います。
▼suneoに対する制限の画面
ユーザーごとに設定したQuota設定状態は、Prismの画面から確認可能ですし、そこから編集が可能です。
では、nobitaユーザーから、CentOS7.3と7.4の2つのISOファイルをコピーしてどうなるかを確認してみましょう。
nobitaユーザーはソフトリミットの5TiBでしたので、今回合計で8.29GB程度のファイルでしたが、問題なくコピーができました。
一方ソフトリミットとはいえ、ポリシーを違反したコピーが行われていますので、管理者には以下のような形でアラートのメールが届いています。
一歩で、ユーザー、suneoは、ファイルコピーが1GiBで制限されるかを確認してみましょう。
suneoは、Redhat Enterprise Linux 7.4のISO(3.78GB)をコピーしてみましょう。
ちなみにsuneoの場合、いきなり容量超過したファイルをコピーしようとしてファイルサーバー(AFS)から拒否されているので、この場合、通知のメールは管理者には送られません。
これで、ユーザーごとにQuotaの動作が正常に行われていることがわかります。
次回はアクセス権限とABEについて紹介をしたいと思います。
2017年9月21日木曜日
AFS(Acropolis File Service)を使ってみよう その１
前回までに、AFSの導入と構成を確認しました。
では、実際に共有フォルダを作成してみたいと思います。
PrismのAFSメニューから展開したAFSのサービスを選択し、「+Share」をクリックします。
ここで、共有フォルダを作成します。
ここでのパラメーターは、以下の通りです。
NAME:
共有フォルダ（ディレクトリ）名です。日本語の入力はできませんので必ず半角英数で設定します。
FILE SERVER:
AFSのサービスを選択
MAX SHARE SIZE:
Quotaサイズの設定
DESCRIPTION:
共有フォルダの説明
日本語の入力はできますが、正しく登録されず、次回開いたときに空白で表示されるため、実質日本語には対応していません。必ず半角英数で設定します。
Enable Access Based Enumeration(ABE):
アクセスベースの列挙を有効にする
Self Service Portal:
バックアップセルフサービスポータルを有効にする
今回は、共有名にAllShare、Quotaに1GiB、DESCRIPTIONに共有フォルダの説明を記載し、保存します。今回はWindows 10 x64 1703 Buildを用意し、AFSで設定した「toriten.oita」ドメインに参加してしたクライアントになります。
では、Windowsクライアントから、共有フォルダを確認してみましょう。
「\\afs01.toriten.oita」にアクセスすると共有フォルダが見えていることがわかります。
Home共有フォルダは、ユーザーホームの領域となりデフォルトで作成されるものとなります。
では、AllShareに、CentOS7.4のISOファイル「4.21GB」のファイルをコピーしてみたいと思います。
想定通り空き容量が足りませんというエラーが出ました。
これはQuotaで1TiBの設定がなされていたことに起因します。
これで、共有フォルダ全体に対してQuotaを設定することができることがわかりました。
では、ユーザーごとに設定を行うことはできるのでしょうか？
これは、Quota Policyで行うことが可能です。
Prism画面から、共有フォルダ「AllShare」を選択し「Quota Policy」をクリックします。
ここで、ユーザー毎のQuota設定や通知の設定を行うことが可能です。
USER OR GROUP:
制限をしたいADのユーザーをUPN形式（ユーザー名＠ドメイン名）で入力します。
このユーザー項目に一度に複数名を入力することはできません。ただし1ユーザーごとに設定をしていけば、複数のユーザーを入力することができます。
QUOTA:
容量制限値を設定
ENFORCEMENT TYPE:
Hard Limit:容量制限を遵守し、違反した場合は通知を飛ばす
Soft Limit:容量超過しても動作をさせるが通知が飛を飛ばす
この容量は、GiB単位での設定となり、MiBでの設定はできません。
0.5GiBなどと入力してもその値は無効です。
ADDITIONAL EMAIL RECIPIENT:
このQuota設定に対する通知メールアドレスを追加する。
ここで重要なことは、共有フォルダで先ほど1TiBのQuotaを設定しましたが、あの値が一番最初に適用される容量制限になりますので、このユーザー個別で3TiBなどと全体のQuotaよりも大きなサイズのQuotaを設定しても、共有フォルダ全体にかけた1TiBのQuotaサイズを超えることはできません。
では、次回により細かい設定を入力の上、動作を確認してみたいと思います。
では、実際に共有フォルダを作成してみたいと思います。
PrismのAFSメニューから展開したAFSのサービスを選択し、「+Share」をクリックします。
ここで、共有フォルダを作成します。
ここでのパラメーターは、以下の通りです。
NAME:
共有フォルダ（ディレクトリ）名です。日本語の入力はできませんので必ず半角英数で設定します。
FILE SERVER:
AFSのサービスを選択
MAX SHARE SIZE:
Quotaサイズの設定
DESCRIPTION:
共有フォルダの説明
日本語の入力はできますが、正しく登録されず、次回開いたときに空白で表示されるため、実質日本語には対応していません。必ず半角英数で設定します。
Enable Access Based Enumeration(ABE):
アクセスベースの列挙を有効にする
Self Service Portal:
バックアップセルフサービスポータルを有効にする
今回は、共有名にAllShare、Quotaに1GiB、DESCRIPTIONに共有フォルダの説明を記載し、保存します。今回はWindows 10 x64 1703 Buildを用意し、AFSで設定した「toriten.oita」ドメインに参加してしたクライアントになります。
では、Windowsクライアントから、共有フォルダを確認してみましょう。
「\\afs01.toriten.oita」にアクセスすると共有フォルダが見えていることがわかります。
Home共有フォルダは、ユーザーホームの領域となりデフォルトで作成されるものとなります。
では、AllShareに、CentOS7.4のISOファイル「4.21GB」のファイルをコピーしてみたいと思います。
想定通り空き容量が足りませんというエラーが出ました。
これはQuotaで1TiBの設定がなされていたことに起因します。
これで、共有フォルダ全体に対してQuotaを設定することができることがわかりました。
では、ユーザーごとに設定を行うことはできるのでしょうか？
これは、Quota Policyで行うことが可能です。
Prism画面から、共有フォルダ「AllShare」を選択し「Quota Policy」をクリックします。
ここで、ユーザー毎のQuota設定や通知の設定を行うことが可能です。
USER OR GROUP:
制限をしたいADのユーザーをUPN形式（ユーザー名＠ドメイン名）で入力します。
このユーザー項目に一度に複数名を入力することはできません。ただし1ユーザーごとに設定をしていけば、複数のユーザーを入力することができます。
QUOTA:
容量制限値を設定
ENFORCEMENT TYPE:
Hard Limit:容量制限を遵守し、違反した場合は通知を飛ばす
Soft Limit:容量超過しても動作をさせるが通知が飛を飛ばす
この容量は、GiB単位での設定となり、MiBでの設定はできません。
0.5GiBなどと入力してもその値は無効です。
ADDITIONAL EMAIL RECIPIENT:
このQuota設定に対する通知メールアドレスを追加する。
ここで重要なことは、共有フォルダで先ほど1TiBのQuotaを設定しましたが、あの値が一番最初に適用される容量制限になりますので、このユーザー個別で3TiBなどと全体のQuotaよりも大きなサイズのQuotaを設定しても、共有フォルダ全体にかけた1TiBのQuotaサイズを超えることはできません。
では、次回により細かい設定を入力の上、動作を確認してみたいと思います。
2017年9月20日水曜日
AFS(Acropolis File Service)の紹介と導入方法 その４
前回までにAFSの展開手法をご紹介しました。
AFSの展開が始まると、VAが自動的に展開されます。
展開の状態は、画面上部のタスクを見て確認しましょう。
▼展開中のタスクの画面
FSVMの展開は、環境によって異なりますが、今回の3ノードの環境では、１５分もかからない程度でした。
さて、VA展開後いきなり設定をしてもよいのですが、以下の内容が自動的に処理されているはずのですので、念のため確認をしてきましょう。
1.AFSのコンピューターアカウントが自動作成（登録）されているか
こちらは、AD参加時に自動的にコンピューターアカウントが登録されますので、念のため確認しておきます。AD参加時にOUを指定していない場合、 「Computers」のOUに登録されます。
AFSのコンピューターアカウントを見てみるとAFSのバージョンも見えることがわかります。
2.AFSのサービス名称の名前引きとFSVMの管理系の名前引き
AFSで、FSVMが3台展開された場合、FSVMの数分だけ、DNSレコードが登録されている必要があります。
今回のAFSのサービスFQDNは、「afs01.toriten.oita」ですので、nslookupで、このFQDNを正引きで引いた場合、各FSVMのサービス系のIPアドレスがかえってくることを確認します。
実際にnslookupで確認してみましょう。
AFSにRangeで割り当てたIPアドレスが1つのホスト名に対して割り当てられていることが確認できます。
一方で、管理系側の名前引きも確認します。
FSVMの各ホスト名は、Prismの各FSVMホスト名を参照することで確認可能です。
実際にnslookupで確認をしてみます。
今回は管理系とサービス系を同じセグメントにしたため、サービス系のIPでDNSレコードが反映されていることがわかります。サービス系とCVMと通信する管理系を別のセグメント（VLAN)にした場合は、そのIPアドレスが正しく反映されていることを確認しましょう。
稀にですが、DNSにレコードが追加されないことがあります。
その場合は、手動でAレコードを作成して、nslookupにて名前引きができることを確認してください。
事前準備、展開、確認はこれで終わりです。
次に、PrismのVolumeGroupを見てみましょう。
たくさんのVolumeGroupができており、それぞれのVolumeGroupで、6つのLUNが構成されていることがわかります。
一方AFSのFSVMで、iscsiadmコマンドを使って、マウントの状況を見てみましょう。
今回は、上記の0b8から始まるiSCSIマウントポイントの状況を確認しましたが、FSVMで、マウントされていることが見てわかります。
また、FSVMでzpoolの情報を確認してみましょう。
ZFSでiSCSIでマウントされたLUNがZFSで構成されていることがわかります。
おそらく、複数のiSCSIで作成されたLUNをZFSで大きな1つのドライブとして管理をしてるように思われます。
上記の情報から、VoluemGroupで作成されているLUNの2つは、メタデーター用として構成されていることもこの情報からわかります。
一方、ストレージコンテナもＡＦＳ用に作成されたコンテナが増えていることがわかります。
「Nutanix_AFSの名称_ctr」というストレージコンテナが自動的に作成されます。
次回から、実際の使ってみよう編として、AFSの設定やクライアントからどう見えるかなどを検証してみましょう。
AFSの展開が始まると、VAが自動的に展開されます。
展開の状態は、画面上部のタスクを見て確認しましょう。
▼展開中のタスクの画面
FSVMの展開は、環境によって異なりますが、今回の3ノードの環境では、１５分もかからない程度でした。
さて、VA展開後いきなり設定をしてもよいのですが、以下の内容が自動的に処理されているはずのですので、念のため確認をしてきましょう。
1.AFSのコンピューターアカウントが自動作成（登録）されているか
こちらは、AD参加時に自動的にコンピューターアカウントが登録されますので、念のため確認しておきます。AD参加時にOUを指定していない場合、 「Computers」のOUに登録されます。
AFSのコンピューターアカウントを見てみるとAFSのバージョンも見えることがわかります。
2.AFSのサービス名称の名前引きとFSVMの管理系の名前引き
AFSで、FSVMが3台展開された場合、FSVMの数分だけ、DNSレコードが登録されている必要があります。
今回のAFSのサービスFQDNは、「afs01.toriten.oita」ですので、nslookupで、このFQDNを正引きで引いた場合、各FSVMのサービス系のIPアドレスがかえってくることを確認します。
実際にnslookupで確認してみましょう。
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Users\Administrator>nslookup
既定のサーバー: dc01.toriten.oita
Address: localhost
> afs01.toriten.oita
既定のサーバー: dc01.toriten.oita
Address: localhost
名前: afs01.toriten.oita
Addresses: 192.168.38.38
192.168.38.37
192.168.38.36
>
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Users\Administrator>nslookup
既定のサーバー: dc01.toriten.oita
Address: localhost
> afs01.toriten.oita
既定のサーバー: dc01.toriten.oita
Address: localhost
名前: afs01.toriten.oita
Addresses: 192.168.38.38
192.168.38.37
192.168.38.36
>
AFSにRangeで割り当てたIPアドレスが1つのホスト名に対して割り当てられていることが確認できます。
一方で、管理系側の名前引きも確認します。
FSVMの各ホスト名は、Prismの各FSVMホスト名を参照することで確認可能です。
実際にnslookupで確認をしてみます。
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Users\Administrator>nslookup
既定のサーバー: dc01.toriten.oita
Address: localhost
> ntnx-afs01-1.toriten.oita
既定のサーバー: dc01.toriten.oita
Address: localhost
名前: ntnx-afs01-1.toriten.oita
Addresses: 192.168.38.36
> ntnx-afs01-2.toriten.oita
既定のサーバー: dc01.toriten.oita
Address: localhost
名前: ntnx-afs01-2.toriten.oita
Addresses: 192.168.38.37
> ntnx-afs01-3.toriten.oita
既定のサーバー: dc01.toriten.oita
Address: localhost
名前: ntnx-afs01-3.toriten.oita
Addresses: 192.168.38.38
>
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Users\Administrator>nslookup
既定のサーバー: dc01.toriten.oita
Address: localhost
> ntnx-afs01-1.toriten.oita
既定のサーバー: dc01.toriten.oita
Address: localhost
名前: ntnx-afs01-1.toriten.oita
Addresses: 192.168.38.36
> ntnx-afs01-2.toriten.oita
既定のサーバー: dc01.toriten.oita
Address: localhost
名前: ntnx-afs01-2.toriten.oita
Addresses: 192.168.38.37
> ntnx-afs01-3.toriten.oita
既定のサーバー: dc01.toriten.oita
Address: localhost
名前: ntnx-afs01-3.toriten.oita
Addresses: 192.168.38.38
>
今回は管理系とサービス系を同じセグメントにしたため、サービス系のIPでDNSレコードが反映されていることがわかります。サービス系とCVMと通信する管理系を別のセグメント（VLAN)にした場合は、そのIPアドレスが正しく反映されていることを確認しましょう。
稀にですが、DNSにレコードが追加されないことがあります。
その場合は、手動でAレコードを作成して、nslookupにて名前引きができることを確認してください。
事前準備、展開、確認はこれで終わりです。
次に、PrismのVolumeGroupを見てみましょう。
たくさんのVolumeGroupができており、それぞれのVolumeGroupで、6つのLUNが構成されていることがわかります。
一方AFSのFSVMで、iscsiadmコマンドを使って、マウントの状況を見てみましょう。
nutanix@NTNX-192-168-38-42-A-FSVM:~$ iscsiadm -m session | grep 08b
tcp: [10] 192.168.38.40:3260,1 iqn.2010-06.com.nutanix:08b3486e-4c14-475d-ab26-be127f95c159-tgt4 (non-flash)
tcp: [11] 192.168.38.40:3260,1 iqn.2010-06.com.nutanix:08b3486e-4c14-475d-ab26-be127f95c159-tgt2 (non-flash)
tcp: [12] 192.168.38.40:3260,1 iqn.2010-06.com.nutanix:08b3486e-4c14-475d-ab26-be127f95c159-tgt5 (non-flash)
tcp: [7] 192.168.38.40:3260,1 iqn.2010-06.com.nutanix:08b3486e-4c14-475d-ab26-be127f95c159-tgt3 (non-flash)
tcp: [8] 192.168.38.40:3260,1 iqn.2010-06.com.nutanix:08b3486e-4c14-475d-ab26-be127f95c159-tgt0 (non-flash)
tcp: [9] 192.168.38.40:3260,1 iqn.2010-06.com.nutanix:08b3486e-4c14-475d-ab26-be127f95c159-tgt1 (non-flash)
tcp: [10] 192.168.38.40:3260,1 iqn.2010-06.com.nutanix:08b3486e-4c14-475d-ab26-be127f95c159-tgt4 (non-flash)
tcp: [11] 192.168.38.40:3260,1 iqn.2010-06.com.nutanix:08b3486e-4c14-475d-ab26-be127f95c159-tgt2 (non-flash)
tcp: [12] 192.168.38.40:3260,1 iqn.2010-06.com.nutanix:08b3486e-4c14-475d-ab26-be127f95c159-tgt5 (non-flash)
tcp: [7] 192.168.38.40:3260,1 iqn.2010-06.com.nutanix:08b3486e-4c14-475d-ab26-be127f95c159-tgt3 (non-flash)
tcp: [8] 192.168.38.40:3260,1 iqn.2010-06.com.nutanix:08b3486e-4c14-475d-ab26-be127f95c159-tgt0 (non-flash)
tcp: [9] 192.168.38.40:3260,1 iqn.2010-06.com.nutanix:08b3486e-4c14-475d-ab26-be127f95c159-tgt1 (non-flash)
今回は、上記の0b8から始まるiSCSIマウントポイントの状況を確認しましたが、FSVMで、マウントされていることが見てわかります。
また、FSVMでzpoolの情報を確認してみましょう。
nutanix@NTNX-192-168-38-42-A-FSVM:~$ sudo zpool status
pool: zpool-NTNX-afs01-e5f60169-abb1-4d67-9197-888d2df153b8-08b3486e-4c14-475d-ab26-be127f95c159
state: ONLINE
scan: none requested
trim: none requested
config:
NAME STATE READ WRITE CKSUM
zpool-NTNX-afs01-e5f60169-abb1-4d67-9197-888d2df153b8-08b3486e-4c14-475d-ab26-be127f95c159 ONLINE 0 0 0
sdn ONLINE 0 0 0
sdl ONLINE 0 0 0
sdj ONLINE 0 0 0
sdk ONLINE 0 0 0
meta
sdo ONLINE 0 0 0
sdm ONLINE 0 0 0
errors: No known data errors
pool: zpool-NTNX-afs01-e5f60169-abb1-4d67-9197-888d2df153b8-08b3486e-4c14-475d-ab26-be127f95c159
state: ONLINE
scan: none requested
trim: none requested
config:
NAME STATE READ WRITE CKSUM
zpool-NTNX-afs01-e5f60169-abb1-4d67-9197-888d2df153b8-08b3486e-4c14-475d-ab26-be127f95c159 ONLINE 0 0 0
sdn ONLINE 0 0 0
sdl ONLINE 0 0 0
sdj ONLINE 0 0 0
sdk ONLINE 0 0 0
meta
sdo ONLINE 0 0 0
sdm ONLINE 0 0 0
errors: No known data errors
ZFSでiSCSIでマウントされたLUNがZFSで構成されていることがわかります。
おそらく、複数のiSCSIで作成されたLUNをZFSで大きな1つのドライブとして管理をしてるように思われます。
上記の情報から、VoluemGroupで作成されているLUNの2つは、メタデーター用として構成されていることもこの情報からわかります。
一方、ストレージコンテナもＡＦＳ用に作成されたコンテナが増えていることがわかります。
「Nutanix_AFSの名称_ctr」というストレージコンテナが自動的に作成されます。
次回から、実際の使ってみよう編として、AFSの設定やクライアントからどう見えるかなどを検証してみましょう。
2017年9月19日火曜日
AFS(Acropolis File Service)の紹介と導入方法 その３
前回までにAFS展開までの諸準備を行いました。
この3回目の投稿では、いよいよAFSの構成する上での肝な部分に入ります。
ウィザードのClient Networkの項になります。
ここで重要なことは、AFSのFSVMは、NIC2枚刺しの構成であるということです。
ADやAFSが提供するCIFSのサービスは、このClientSideネットワークから提供されます。
一方で前回の項で記載しましたが、AFSは、Volume Serviceを利用するためCVMとも通信を行います。そのため、いわゆるサービスを提供するネットワークがClient Networkという定義で、CVMと通信するネットワーク、管理系のネットワークをStorage Networkという形で２つのセグメントで通信をする形となります。
ここでは、クライアントからのリクエストとADや各種関連サーバーと通信をサービス系のネットワークを定義します。
PORT GROUP:
vSphereのVLANに相当するポートグループを選択します。
ここでは、サービス系を提供するネットワークのポートグループを選択します。
GATEWAY:
AFSのネットワークのデフォルトゲートウェイを入力します。
（デフォルトゲートウェイは必須入力項目です）
NETWORK:
AFSのネットワークのサブネットマスクを入力します。
IP Address:
各FSVMに付与するIPアドレスを入力します。
各FSVMはすべて同一のセグメントである必要があります。
FSVMのIPアドレスは、 Range（範囲）で設定をすることが推奨されます。
必要なIPアドレスは、展開するFSVMの数とイコールになります。
そのため、FSVMが必要な最大数である16個の範囲を、設計時にあらかじめIPアドレスとして予約しておくと、急な変更等があっても対応することが可能だと思います。
やむを得ず、連続した範囲でIPアドレスが用意できない場合、複数のRange設定が可能です。
今回は、3台のFSVMを展開する形で進めていますので、3つのIPアドレスを割り振ります。
DNS IP:
FSVMに設定するDNSサーバーのIPアドレスを入力します。
AFSは、ADと連携を行うため、通常はADで利用されているDNSサーバーのIPを入力します。
カンマ区切りで複数のDNSサーバーのIPを入力可能です。
NTP SERVERS:
FSVMに設定するNTPサーバーのIPアドレスを入力します。
ADとの認証にケルベロス認証が使われる背景から、時刻同期は大切な機能ですので、必ず入力をしましょう。 (NTPサーバーの入力は必須です）
カンマ区切りで複数のDNSサーバーのIPを入力可能です。
今回は、FSVMのIPアドレスは範囲設定で行うこととし、以下のような内容でウィザードを進めます。
必要なパラメーターを入力後、Nextをクリックします。
次は、NutanixのCVMと通信するためのストレージネットワークのIPアドレス設定画面が表示されます。
PORT GROUP:
vSphereのVLANに相当するポートグループを選択します。
ここでは、CVMと通信ができる管理系を提供するネットワークのポートグループを選択します。
GATEWAY:
IPを付与するセグメントのネットマスクを入力します。
NETWORK:
IPを付与するセグメントのネットマスクを入力します。
IP Address:
各FSVMに付与するCVMと通信が可能なIPアドレスを入力します。
各FSVMはすべて同一のセグメントである必要があります。
FSVMのIPアドレスは、 Range（範囲）で設定をすることが推奨されます。
このIPアドレスは、FSVMの個数＋1個のIPアドレスが必要となります。
この場合、3台のFSVMを展開する形で進めていますので、Storage Networkで必要なIPアドレスの個数は4個となります。
そのため、FSVMが必要な最大数である17個の範囲を、設計時にあらかじめIPアドレスとして予約しておくと、急な変更等があっても対応することが可能だと思います。
やむを得ず、連続した範囲でIPアドレスが用意できない場合、複数のRange設定が可能です。
ここで出てくるのが、小規模な環境や検証用のネットワークの場合、サービス系と管理系が同一のネットワークであるケースがあります。
この場合であっても、Storage Network側にIPを付与する必要がありますが、Client Networkで付与したIPアドレスと同一セグメントのIPアドレスを付与することで、解決できます。
今回は検証ネットワークということで、Client Networkと同一のセグメントIPをRangeで設定しウィザードを進めます。
必要なパラメーターを入力したら、Nextをクリックします。
この項では、AFSが参加するADの設定を行います。
ACTIVE DIRECTORY DETAILS:
ADのドメイン名を入力します。
USERNAME:
AD参加のユーザー名を指定します。
PASSWORD:
AD参加時のパスワードを入力します。
Show Advanced Optionsの項目は通常は利用しませんが、AD参加時にうまくいかない時や個別設定をしたい場合に入力します。
PREFERRED DOMAIN CONTROLLER:
AD参加時に参加処理を行うドメインコントローラーを指定する場合に利用します。
指定したいドメインコントローラー(DC)をFQDNで入力します。
ORGANIZATIONAL UNIT:
AFSがADに参加する際のコンピューターアカウントを配置するOUを指定します。
今回は、Advacned Optionは利用せず、通常の方法でAD参加のパラメーターを入力します。
パラメーター入力後、最後の確認に進みますのでNextをクリックします。
最後のSammary画面が表示されます。
FSVMのスペック構成が表示されるとともに、Protection Domainの名称が表示されています。
PROTECTION DOMAIN NAME:
AFSで保存されたデーターをNutanixのスナップショット機能を利用してバックアップを行うバックアップジョブを生成する際の、ジョブ名称となります。任意の名前を付けることが可能です。
今回はウィザードで自動定義された名前ではなく、AFS-BACKUPという名称に変え、ウィザードを完了します。
確認後、Createをクリックしてください。
あとは、FSVMが展開されるのを待つばかりです。
ファイルサーバーの構築がわずか数クリックだけで終わるというのは、はやりNutanixのシンプルというところを表しているように思います。
次回からは、AFSの利用についてみていきたいと思います。
この3回目の投稿では、いよいよAFSの構成する上での肝な部分に入ります。
ウィザードのClient Networkの項になります。
ここで重要なことは、AFSのFSVMは、NIC2枚刺しの構成であるということです。
ADやAFSが提供するCIFSのサービスは、このClientSideネットワークから提供されます。
一方で前回の項で記載しましたが、AFSは、Volume Serviceを利用するためCVMとも通信を行います。そのため、いわゆるサービスを提供するネットワークがClient Networkという定義で、CVMと通信するネットワーク、管理系のネットワークをStorage Networkという形で２つのセグメントで通信をする形となります。
ここでは、クライアントからのリクエストとADや各種関連サーバーと通信をサービス系のネットワークを定義します。
PORT GROUP:
vSphereのVLANに相当するポートグループを選択します。
ここでは、サービス系を提供するネットワークのポートグループを選択します。
GATEWAY:
AFSのネットワークのデフォルトゲートウェイを入力します。
（デフォルトゲートウェイは必須入力項目です）
NETWORK:
AFSのネットワークのサブネットマスクを入力します。
IP Address:
各FSVMに付与するIPアドレスを入力します。
各FSVMはすべて同一のセグメントである必要があります。
FSVMのIPアドレスは、 Range（範囲）で設定をすることが推奨されます。
必要なIPアドレスは、展開するFSVMの数とイコールになります。
そのため、FSVMが必要な最大数である16個の範囲を、設計時にあらかじめIPアドレスとして予約しておくと、急な変更等があっても対応することが可能だと思います。
やむを得ず、連続した範囲でIPアドレスが用意できない場合、複数のRange設定が可能です。
今回は、3台のFSVMを展開する形で進めていますので、3つのIPアドレスを割り振ります。
DNS IP:
FSVMに設定するDNSサーバーのIPアドレスを入力します。
AFSは、ADと連携を行うため、通常はADで利用されているDNSサーバーのIPを入力します。
カンマ区切りで複数のDNSサーバーのIPを入力可能です。
NTP SERVERS:
FSVMに設定するNTPサーバーのIPアドレスを入力します。
ADとの認証にケルベロス認証が使われる背景から、時刻同期は大切な機能ですので、必ず入力をしましょう。 (NTPサーバーの入力は必須です）
カンマ区切りで複数のDNSサーバーのIPを入力可能です。
今回は、FSVMのIPアドレスは範囲設定で行うこととし、以下のような内容でウィザードを進めます。
必要なパラメーターを入力後、Nextをクリックします。
次は、NutanixのCVMと通信するためのストレージネットワークのIPアドレス設定画面が表示されます。
PORT GROUP:
vSphereのVLANに相当するポートグループを選択します。
ここでは、CVMと通信ができる管理系を提供するネットワークのポートグループを選択します。
GATEWAY:
IPを付与するセグメントのネットマスクを入力します。
NETWORK:
IPを付与するセグメントのネットマスクを入力します。
IP Address:
各FSVMに付与するCVMと通信が可能なIPアドレスを入力します。
各FSVMはすべて同一のセグメントである必要があります。
FSVMのIPアドレスは、 Range（範囲）で設定をすることが推奨されます。
このIPアドレスは、FSVMの個数＋1個のIPアドレスが必要となります。
この場合、3台のFSVMを展開する形で進めていますので、Storage Networkで必要なIPアドレスの個数は4個となります。
そのため、FSVMが必要な最大数である17個の範囲を、設計時にあらかじめIPアドレスとして予約しておくと、急な変更等があっても対応することが可能だと思います。
やむを得ず、連続した範囲でIPアドレスが用意できない場合、複数のRange設定が可能です。
ここで出てくるのが、小規模な環境や検証用のネットワークの場合、サービス系と管理系が同一のネットワークであるケースがあります。
この場合であっても、Storage Network側にIPを付与する必要がありますが、Client Networkで付与したIPアドレスと同一セグメントのIPアドレスを付与することで、解決できます。
今回は検証ネットワークということで、Client Networkと同一のセグメントIPをRangeで設定しウィザードを進めます。
必要なパラメーターを入力したら、Nextをクリックします。
この項では、AFSが参加するADの設定を行います。
ACTIVE DIRECTORY DETAILS:
ADのドメイン名を入力します。
USERNAME:
AD参加のユーザー名を指定します。
PASSWORD:
AD参加時のパスワードを入力します。
Show Advanced Optionsの項目は通常は利用しませんが、AD参加時にうまくいかない時や個別設定をしたい場合に入力します。
PREFERRED DOMAIN CONTROLLER:
AD参加時に参加処理を行うドメインコントローラーを指定する場合に利用します。
指定したいドメインコントローラー(DC)をFQDNで入力します。
ORGANIZATIONAL UNIT:
AFSがADに参加する際のコンピューターアカウントを配置するOUを指定します。
今回は、Advacned Optionは利用せず、通常の方法でAD参加のパラメーターを入力します。
パラメーター入力後、最後の確認に進みますのでNextをクリックします。
最後のSammary画面が表示されます。
FSVMのスペック構成が表示されるとともに、Protection Domainの名称が表示されています。
PROTECTION DOMAIN NAME:
AFSで保存されたデーターをNutanixのスナップショット機能を利用してバックアップを行うバックアップジョブを生成する際の、ジョブ名称となります。任意の名前を付けることが可能です。
今回はウィザードで自動定義された名前ではなく、AFS-BACKUPという名称に変え、ウィザードを完了します。
確認後、Createをクリックしてください。
あとは、FSVMが展開されるのを待つばかりです。
ファイルサーバーの構築がわずか数クリックだけで終わるというのは、はやりNutanixのシンプルというところを表しているように思います。
次回からは、AFSの利用についてみていきたいと思います。
登録:
投稿 (Atom)