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で確認してみましょう。

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つは、メタデーター用として構成されていることもこの情報からわかります。

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

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