2017年10月10日火曜日

Nutanix X-Rayの紹介と活用法 その3

では、早速X-Rayを実際にデプロイしたいと思いますが、その前に必要な環境をまずは押さえておきましょう。

X-Rayは、仮想アプライアンスで提供されます。
中のOSは、CentOS6.6がベースになっています。
X-Rayを利用するためには、仮想マシンが稼働する環境を用意しなければなりません。X-Rayは、qcow2とovaの2つが提供されています。そのため、AHVでも動作しますし、ESXiでも動作します。
また、VMware WorkstationやFusionなどPCで仮想マシンを稼働させる環境でも動作させることができます。つまりX-RayはNutanix上でない環境でも動作させることができます。

X-Ray稼働環境
  • ESXi5.5~
  • AHV
  • VMware Workstation / Player / Fusion
  • KVM


次に検証できる環境を確認していきましょう。
X-Rayは、Nutanixの環境をテストできることは当たり前ですが、Nutanix以外にESXiで構成された仮想化基盤もテストすることができます。

X-Rayがテストできる環境
  • Nutanix
    • AHV
    • ESXi
  • 非Nutanix
    • ESXi(vCenterが存在すること)




次にX-Rayを稼働させるネットワーク環境です。
X-RayのVAは、NIC2枚挿しの構成になっています。
eth0は、vCenter Serverなどの管理サーバーとの接続できるネットワークにeth1は、DHCPの存在させないネットワーク環境を接続し、そこに検証用の仮想マシンを大量展開し、X-RayのVAと通信します。(IPは、169.254~のIPアドレスを利用します)
そのため、テスト行うNutanixやESXi環境にあらかじめテスト用にVLANを作成しておく必要があります。

▼X-Rayを利用する際のネットワーク構成

また、X-Rayは、インターネットに接続できる環境が必要です。
そのため、インターネットの環境は事前に準備をしておきましょう。


ここまでわかったら、早速X-Rayのバイナリを入手しましょう。
X-Rayのバイナリを取得するには、まずMyNutanixのアカウントを作成する必要があります。

MyNutanix
https://my.nutanix.com/

こちらのアカウントをお持ちでない方は、まずログイン下の「+Create account」からアカウントを作成しましょう。

実際のX-Rayのバイナリは、Nutanix Communityの中にあります。
https://next.nutanix.com/t5/Nutanix-X-Ray/Download-Nutanix-X-Ray-and-Docs/m-p/21754#M6


イメージが、qcow2とOVAの2つがありますので、必要なものをダウンロードしましょう。容量は1.5GB程度ありますのでダウンロードには結構な時間がかかります。

次回は、実際にインポートして動作することろまでもっていきましょう。







2017年10月9日月曜日

Nutanix X-Rayの紹介と活用法 その2

前回はX-Rayができた背景を紹介しました。
では、X-Rayのメリットをご紹介します。

その1
X-Rayは、無料
X-Rayは、無料で提供されています。
Nutanix Communityからダウンロードできますので、だれでも試すことができます。
提供バイナリは、qcow2か、ovfで提供されていますので、仮想マシンが動作する環境があればそれだけで大丈夫です。


その2
X-Rayは、GUIで使いやすい
X-Rayは、GUIで操作できます。
また、従来のテストツールではわかりにくかった、時間軸をもとにした表示をしてくれますので、キャッシュありきの現代ストレージであってもどのタイミングでキャッシュが枯渇して動作が変わったかなどを見ることも可能です。

▼X-RayのGUI画面(サンプルで入っているパフォーマンス画面)


その3
X-Rayは、テストケースが実体のワークロードにかなり近い
X-Rayは、従来のIOパフォーマンス測定ツールと違い、特殊なパラメーターを入れるわけではなく、実体のワークロードの種類があらかじめ設定されており、そこから測定したいワークロードを選ぶだけです。難しいパラメーターをいろいろと設定することもありません。また、HCIという観点に基づいたテストツールのため、ノードを1台ダウンさせた際のパフォーマンス測定を行うシナリオなどもあります。
シナリオは以下のようなしなりが用意されています。

シナリオの種類
Database Colocation
Snapshot Impact
Rolling Upgrade
HCI Workflow
OLTP Simulator
Four CornersMicrobenchmark
Sequential Node Failure
VDI Simulator
Extended Node Failure


その4
X-Rayは、偏りがない
X-RayはNutanixが作ったものなので、Nutanixに有利なように作られているんでしょ?って思われるのは普通だと思います。
しかし、その答えはNOです。
X-Rayは、オープンソースのfio(エフアイオー)を採用しています。
fioは、オープンソースでgithubに公開されていますので、もしfioの動作が偏っていると思われるのであれば、ぜひソースコードを読んでいただければと思います。


無料で、ワークロードは現実的、GUIで使いやすくて、特定のメーカーに偏りがいのであれば、これは使うしかないですね!

次回からは、構成と導入について紹介したいと思います。




2017年10月8日日曜日

Nutanixにかんするウワサを検証その3

Nutanixを拡販していると、こんなウワサ話を聞いたけどホントですか?などの聞かれることがしばしばあります。
これは、Nutanixの情報がまだまだ少ないことも影響しているようですが、正しくない情報がそのまま流れ続けることは、フェアではないと思います。
今回は、Nutanixに対するウワサの第3弾と記載します。


ウワサ1
Nutanixは、台湾メーカーの製品で故障しやすい。

真相
ウソ

これは、前回のウワサ2でも書きましたが、壊れるか壊れにくいかは、個人の判断によるところもでありますので、何とも言いにくいところがありますが、この噂の中で明確な嘘が1点入っています。
それは、「台湾メーカー」という表現です。
Nutanix純正のNXシリーズは、スーパーマイクロ製のハードウェアを利用しています。
スーパーマイクロは"アメリカ"の会社です。

(参考)スーパーマイクロの紹介(wikipedia)
https://ja.wikipedia.org/wiki/Supermicro

スーパーマイクロは、Nutanix以外でも様々なメーカーにOEM/ODMでハードを提供したり、レンタルサーバー事業者など大量のサーバーを必要とする会社で多く使われている大変実績のあるハードウェアであることをまずは理解しておく必要があります。


ウワサ2
Nutanixは、SSDに相当な負荷をかけているのでSSDが短時間で故障する

真相
ウソ

これもまたウソな話ですね。
そもそもHCI製品はどこのハードウェアもSSDの高速なパフォーマンスとHDDの容量コストをうまく使っています。そのため、どのハードウェアにおいてもSSDをフル活用するのは間違いありません。
ここで出てくるのは、Nutanixが採用しているSSDは、耐久性の高いSLCのモデルを採用しています。そのため、壊れにくいパーツを採用していることはきちんと押さえておく必要があります。
一般的に考えても、SSDよりもHDDのほうが壊れやすいことは容易に想像できます。


ウワサ3
Nutanixは、内部構造が複雑で障害が発生すると復旧まで時間を要する

真相
ウソ

Nutanixはソフトウェアですので、ソフトウェア内部プロセスとしては様々なプロセスが動作していることは事実です。
しかし、これらのプロセスに動作異常が発生した場合、Prism側できちんと何が悪いかのエラーがきちんと表示されます。
Nutanixには、優秀な保守エンジニアがそろっていることは前回のウワサ2で紹介した通りです。
従来のサーバー故障の感覚から行くと、サーバー機の不調があった場合、まずサポートセンターに電話をしてコールセンターの方に症状を伝えて、とりあえず保守員に現地に来てもらうという対応をしていただいたこともあります。
保守員は、あーでもないこうでーもないと電話でサポートエンジニアと会話しながら切り分けをするケースはよく見る光景です。
一方で、Nutanixは、ハードウェアは、極限までシンプルにしていますので、まずハードの故障は保守員が直行してあーでもないこーでもないといった切り分けをする必要が全く必要ありません。では、ソフトウェア面での切り分けはというと、NCC(Nutanix Cluster Check)といわれるNutanixを全体にわたってチェックする総合ツールがあります。これは、単純に言えばshow tech-supportみたいなもので、全体の情報をチェックしてクラスター全体の情報を収集します、これを見ることで原因個所をすぐに突き止めることができます。また、Nutanixには、WebEXを使ったリモートサポートがありますので、電話して保守員が来るまでの時間を待つよりも、障害があればすぐに、Nutanixのサポートエンジニアが直接そのNutanixクラスターを遠隔で操作し調査をしますので、従来よりもより高速かつ適切に、短時間で問題を解決できます。


ウワサ4
Nutanixは、ハードウェアとソフトウェアで保守がわかれる

真相
一部ホント、一部ウソ

まず、Nutanix純正を購入し、AHVを利用した場合、このウワサは明確にウソになります。それは、NutanixのハードウェアもAHVもNutanix自身がサポートをしてくれるからです。
では、Nutanix純正を購入し、ESXiを利用した場合どうなるかというと、Nutanixに関するソフトウェア・ハードウェアはNutanixが保守を行い、ESXiの問題はVMwareが保守を行うことになります。
じゃあ、保守は2つの窓口に分かれることになるのですね?と聞かれれば、答えはYesです。保守窓口が2つに分かれると、どちらに聞いてよいのかわからないということと、双方で回答が異なるなどが、不安要素になるかと思います。
そこでNutanixは、Nutanix上で稼働しているもので、Nutanixがハイパーバイザーかの切り分けができない場合は、"Nutanixにまず問い合わせてください"というポリシーがあります。Nutanix側で切り分けとどちらが悪いかの判断、明確にハイパーバイザー側の問題であれば、ハイパーバイザーメーカーへの問い合わせ方法について指南してくれます。
どうしても保守窓口は一本化したいという希望がある場合は、DellEMCのXCシリーズ、Lenovo社のHXシリーズを利用することで、ハイパーバイザーとハードウェア、さらにNutanixの内容までを一括で保守受けしてもらえますので、このような心配は、必要なくなります。


ウワサ5
Nutanixの、重複排除・圧縮機能は使い物にならない

真相
ウソ

これも何が根拠で出てきているのかが全く謎です。
まず、重複排除機能ですが、Nutanixのキャッシュエリアに相当する部分の重複排除機能であるインライン重複排除機能と実際の保存領域の重複排除を行うポストプロセス圧縮の2つがあります。ポストプロセス重複排除機能があります。
この2段階のプロセスを経て、負荷をかけずに重複したデーターをきちんと排除し、容量の削減に寄与します。
重複排除による、重複データー分の要領削減はもちろん行われます。
圧縮機能も、インライン圧縮と、ポストプロセス圧縮の2つの圧縮機能があり、2段階での圧縮を行い高い圧縮率でデーターを保存していきます。
重複排除や圧縮機能は、ストレージコンテナ(Datastore)単位で行うことが可能ですので、複数のストレージコンテナを作成し、用途に合わせて利用することも可能です。

Nutanixは、圧縮機能を利用することを強く推奨しています。
これは、重複排除は保存されるデーターによりどれぐらいの容量が節約できるのかが異なり、サイジングしづらいという問題があります。一方で圧縮は、非圧縮ファイルであれば一定の圧縮がかけられるのは明確で、重複排除に比べてサイジングしやすいというメリットがあります。そのため、圧縮機能を積極的に利用することを推奨していますし、合わせて重複排除機能を利用してさらに容量の削減を行うことは、Nutanixでも普通にできることであり、利用してなにも問題はありません。

▼重複排除・圧縮の設定



さて今回も5つのウワサを紹介しました。
Nutanixは、知名度が上がっていく一方でまだまだ、一般的に情報がいきわたっていない側面もあり、正しくない情報が出回ることもありますが、是非正しい情報に触れていただきたいと思います。




Nutanix X-Rayの紹介と活用法 その1

今回から数回にわたって、Nutanixから提供されているX-Rayについてお話をしていきます。

まず、Nutanix X-Rayはなにかというと、端的な回答をすると「ベンチマークソフト」ということになります。

なぜ、Nutanixがベンチマークソフトウェアを今更出すのかと思われる方もいるかもしれませんが、それには事情があります。

理由その1
キャッシュありき時代のストレージパフォーマンスは測りづらい
ストレージのパフォーマンスは、従来ディスクの本数でIOPSを稼ぐといった手法で速度を上げていました。この時のパフォーマンスを図る際によく利用されていたのがIOMatereでした。
IOMaterは、ディスクパフォーマンスを様々なパラメーター値をもとに計測するとても便利なツールです。しかし、キャッシュなき時代の考え方ですので、キャッシュが効いていると本来のパフォーマンスかどうかが判断できなくなります。

理由その2
実態のワークロードと異なるテストは意味がない
IOMaterは、ランダムライトやシーケンシャルリードなど、様々なIOをシミュレートした動作をしてくれますが、DBでの利用とVDIでの利用では、IOの種類はばらばらであり、ストレージのキャッシュの使われ方も異なります。
キャッシュありきのストレージ時代に、一方的なシナリオだけでパフォーマンスを図っても、それが実体のワークロードと異なっていればそのパフォーマンス値は意味がない元となります。

理由その3
IOテストツールは難しい
IOMaterは、GUIが提供されているので、まだわかりやすいほうですが、世の中で提供されているIOテストツールはCUIしか提供されていないものも多くあります。
また、複雑なパラメーターをもとに、実態のワークロードに近いIOをシミュレートさせようとしますが、そのパラメーターの設定は、経験値がないと設定は難しく、まさにストレージ屋さんの勘と経験が必要になってきます。

この3つの理由から、もっと実態に即したパフォーマンス値を手軽に検証することができないかということから出てきたのが、X-Rayとなります。

次回はX-Rayのメリットを紹介します。



2017年9月27日水曜日

Nutanixって大丈夫なの?Nutanixの事例を紹介

Nutanixは、ハイパーコンバージドインフラストラクチャーという、仮想化にとって最もシンプルで効率のよい、仮想化を最大限に使いやすくするインフラ基盤として誕生しました。
会社は2009年に生まれた会社で、日本でも知名度はだいぶ伸びてきましたが、 まだまだ変な会社とか、マンション経営の会社じゃないのとか、Nutanixという会社を知らない人にとっては、怪しいイメージを持っている人も居るかもしれません。

今日は、Nutanixの導入されている企業を紹介したいと思います。
この導入企業は、Nutanixサイトで公開されています。

まず、公共分野では、
があげられます。
どこも人口の多い都市であることは、見てすぐわかります。
こういった役所の重要な基盤は、Nutanixで稼働しています。
また、事例では公開されていませんが、日本中のかなり多くの市町村や府県でもNutanixの導入が進んでいます。

では次に医療分野を見てみましょう
がメーカー事例としてあげられています。
実は医療分野でもNutanixの導入はかなり進んでいるのですが、まだ出せる事例が少ないというのはあります。ただ、医療分野では電カル導入に伴うVDI導入も盛んですので、事例はどんどん増えるでしょう。


では次に金融を見てみましょう。
医療や金融はシステムの堅牢性や安定動作にかなり厳しい要求をしてきます。
ここで注目は、日本の株式を仕切る、東京証券取引所に導入されているということです。

これは、NutanixのWebスケールな分散の仕組みはこのような大規模でも威力を発揮すると言うことの表れです。言い換えれば、東証で動かせる高度な仕組みをNutanix3ノードで小さな企業でもその俊敏性と利便性が享受されるのは凄いことだと思います。

Nutanixにおいて重要なことは、できたてのスタートアップの企業が社内基盤に最小限のNutanixを導入して、その企業がどんどん成長して、東証に上場したとしても、ずっとNutanixを使い続けることができるのです。企業の成長に合わせてシステムを見直したり、リプレースする必要はありません。Nutanixは会社の成長に合わせて拡張ができます。ずっとその企業とつきあうことのできる基盤であることを是非知っておいてほしいです。

大企業のためNutanixでもなく、中小零細企業のためのNutanixでもなく、どんな企業にもフィットする仮想化基盤がNutanixなのです。

Nutanixの事例はこちらから参照することができます。





2017年9月26日火曜日

AFS(Acropolis File Service)を使ってみよう その6

Acroplis File Service(AFS)が、ファイルサーバーんの機能として十分な機能を持っているということと、必要に応じてむ停止で容量の拡張ができる点や、OneClickUpgradeによる無停止の機能拡張ができるというメリットは、今までの検証でよくわかってきました。

今回は機能ではなく、メンテナンス時のAFSの起動と終了方法について抑えていきたいと思います。

AFSは、無停止でソフトウェアアップグレード(OneClick Upgrade)ができる点や、容量拡張も無停止でできる側面から、AFSを止めてメンテナンスをするということは、まずないといえるでしょう。

ただ、社内の電源設備点検や、移設作業など、なんらかの理由によってNutanixクラスターを停止させる場合、あらかじめAFSのサービスを安全に停止した上で、Nutanixクラスターの停止を行う必要があります。

AFSのシャットダウンは簡単です。

  1. 任意のCVMにSSHでログインします。
  2. 「minerva -a stop」コマンドを入力します
  3. 自動的にAFSのサービスが終了し、AFSのFSVMがシャットダウンされ、パワーオフ状態になります。

以上で終了です。

とても簡単で、かつ、各FSVMをすべてシャットダウンしてくれるのは大変便利です。
シャットダウンはFSVMの数により異なりますが、今回の検証環境では、3台のFSVMで、だいたい3分程度でシャットダウンがで完了しました。

では、起動はというとこちらも簡単で以下の手順で行います。

  1. 任意のCVMにSSHでログインする
  2. 「minerva -a start」 
  3. 自動的にFSVMが起動し、AFSサービスが起動する
こちらもコマンド1つ投げて、あとは待つばかりです。
こちらの起動も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)を使ってみよう その5

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)を使ってみよう その4

前回までに、共有フォルダに対してより細かい権限設定ができることがわかりました。
しかし、ユーザー権限を付与するごとに共有フォルダを作成すると、共有フォルダだらけになり、一般的によく起きゆるファイルサーバーの無法地帯化の一歩に近づいてしまっている気がします。

そのため、共有フォルダを1つ作成しその中のサブフォルダで細かい権限を設定し、共有フォルダの数を減らしつつ、セキュアな環境を作成したいと思います。

まず、Prism画面で、前回までに作成したDivisionShareの設定変更を行います。
FileServerの項で、「DivisionShare」選択し、Updateをクリックします。



オプションとして、「Enable Access Based Enumeration(ABE)」と「Self Service Restore」にチェックを入れ、Saveをクリックします。

では、この状態で2つのフォルダを作成し、権限付与をしたいと思います。

「\\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)を使ってみよう その3

前回はQuotaに対する動作を確認しました。
では、次に権限設定を確認してみましょう。

今回は、DivisionShareという共有ディレクトリを作成し、以下のような権限を設定したいともいます。


氏名ユーザー名権限設定
源 静香shizukaアクセス読書可能
野比 のび太nobitaアクセス読書可能
骨川 スネ夫suneoアクセス読書可能
出木杉 英才dekisugiアクセス読取可能
剛田 武takeshiアクセス不可
※アカウントがみんな名前なのに出木杉君だけ、苗字なのはご愛嬌ということで...。

▼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)を使ってみよう その2

前回までに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について紹介をしたいと思います。





2017年9月21日木曜日

AFS(Acropolis File Service)を使ってみよう その1

前回までに、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サイズを超えることはできません。

では、次回により細かい設定を入力の上、動作を確認してみたいと思います。






2017年9月20日水曜日

AFS(Acropolis File Service)の紹介と導入方法 その4

前回までにAFSの展開手法をご紹介しました。

AFSの展開が始まると、VAが自動的に展開されます。
展開の状態は、画面上部のタスクを見て確認しましょう。

▼展開中のタスクの画面

FSVMの展開は、環境によって異なりますが、今回の3ノードの環境では、15分もかからない程度でした。


さて、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

>

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


>

今回は管理系とサービス系を同じセグメントにしたため、サービス系の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)

今回は、上記の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

ZFSでiSCSIでマウントされたLUNがZFSで構成されていることがわかります。

おそらく、複数のiSCSIで作成されたLUNをZFSで大きな1つのドライブとして管理をしてるように思われます。

上記の情報から、VoluemGroupで作成されているLUNの2つは、メタデーター用として構成されていることもこの情報からわかります。

一方、ストレージコンテナもAFS用に作成されたコンテナが増えていることがわかります。
「Nutanix_AFSの名称_ctr」というストレージコンテナが自動的に作成されます。




次回から、実際の使ってみよう編として、AFSの設定やクライアントからどう見えるかなどを検証してみましょう。