nutanix メモブログ

Nutanix についてメモしていくブログです。

Nutanix .NEXT での新機能整理

Nutanix .NEXT に参加しましたが、そこで発表された新機能について

簡単にまとめておきます

 

情報は原文の投稿時のものですので、今後の製品情報と
差異が生じている場合があります。

 

■ Nutanix Era

 

<機能>

⇒ Nutanix の機能で ワンクリックで データベースを
    プロビジョニング、コピー、特定時点でのリストアを可能にする。

⇒ データベースの ワンタッチ・タイムマシン
    ⇒ 簡単にスナップショットを作成する。

⇒ ワンクリックデータベースクローン/リフレッシュ
    ⇒ データベースのクローン処理や特定時点へのリストア処理をワンクリックで実施

<対応>
 ⇒ Oracle と Postgres SQL
   ⇒ 今後、Microsoft SQL ServerMySQL も対応予定

<リリース>
   ⇒ 2018年後半予定です。

<補足>
・ Nutanix の機能として、Amazon RDS(データベースの簡易セットアップ) のようなものを持たせる。
仮想マシンのサイズや容量、ネットワーク情報を指定してデータベース立ち上げ

 

 

■ Nutanix Flow

 

<機能>
   ⇒ アプリケーション間のネットワークセキュリティを実現
   ⇒ 特定のインスタンス(アプリケーション)対して アクセスできる
        ホストを制限する。(IPアドレスが変わってもホスト単位なので大丈夫)
          ⇒ 簡単に仮想ネットワークが構築できる。

    ⇒ マイクロセグメンテーション
       方法としては、Prism Central の Explore から VM を選択して
          [ Action ] - [ Quarantine VM ]
             から
          Strict ・・ VMをネットワークから隔離
          Forensics ・・・ 特定の条件を除いて VM から 隔離

           参考 : http://www.vjenner.com/2018/04/nutanix-flow-networking/

  ⇒ 可視化
          各インスタンス(アプリケーション間)でどのようなトラフィック制御が
          行われているかを可視化することができる。

<今後の予定>
   ⇒ ネットワーク構成変更自動化を計画している。
       これは Netsli という機能を使用し、ネットワークの状態を
      分析して問題ある構成を通知/状態遷移させる方式です。

        Flow + Netsli は 2018年後半で利用可能予定

■ Nutanix Beam

 

<機能>
    ⇒ マルチクラウドでの 運用管理(コスト管理) が実現可能
    ⇒ クラウドインスタンスを利用していない時間が多く存在するケースもあり
        そのような時間を無駄にしないように、クラウドの使用状況を追跡し、
        マップ化して、クラウド最適化に役立てるようにする。

<対応>
     ⇒ AWS と Azure

<リリース>
      ⇒ 現在、14日間の無料トライアルつきで使用可能です。
            https://www.nutanix.jp/products/beam/

 

Nutanix の名前の部分は知れ渡ってきてますが、Nutanixの

新機能はまだまだ知られていないので、新機能がNutanix の売りに

なっていってくれればと願ってます。

 

GOOGLE CLOUD LOAD BALANCING(HTTP(S) 負荷分散)

最近、Google Cloud も勉強中です。

そこで軽くまとめたメモを記事にしておこうかと思います。

※ 詳細は、Google Cloud の紹介ページのほうが詳しいです。

    イメージをわかりやすくするために図で記載していく予定です。

 

まず、Google Cloud Load Balancing の HTTP(S) 負荷分散イメージについてです。

負荷分散は下記のように実施されます。

 

 

f:id:Yu-K-Syo2:20180423042637p:image

 

 

説明が足りていない部分は多いですが、大きな流れでこのとおりです。

 

なお、HTTPS の場合は以下の条件がありますので、ご確認ください。

 

1.ターゲット HTTP プロキシではなくターゲット HTTPS プロキシを使用します。

2.ロードバランサのターゲット HTTPS プロキシに署名済みの SSL 証明書が

       少なくとも1 つインストールされている必要があります。

3.    クライアント SSL セッションはロードバランサで終端します。
      ロードバランサとインスタンス間のセッションは、HTTPS(推奨)と

      HTTP のどちらでもかまいません。
      HTTPS を使用する場合は、バックエンド サービスの各インスタンス

      SSL 証明書を持つ必要があります。

 

以下、個別説明

 

グローバル転送ルールとアドレス

トラフィックを IP アドレス、ポート、プロトコル別に、ターゲット プロキシと

URL マップ、1つ以上のバックエンドで構成される負荷分散構成にルーティング

します。

 

各グローバル転送ルールは、使用するアプリケーションの DNS レコードで

使用できる単一のグローバル IP アドレスを提供します



ターゲット プロキシ

ターゲット プロキシはクライアントからの HTTP(S) 接続を終了し、

1 つ以上のグローバル転送ルールから参照され、URL マップへの受信リクエストを

ルーティングします。

 

URL マップ

URL マップは、URL に基づいて適切なバックエンド サービスにリクエストを

ルーティングするマッチング パターンを定義します。

デフォルトのサービスは、指定されたホストルールまたはパスマッチング ルールに

一致しないすべてのリクエストを処理するように定義されています

 

SSL 証明書

HTTPS 負荷分散を使用する場合は、ターゲット HTTPS プロキシに 1 つ以上の

SSL 証明書をインストールする必要があり、最大 10 個の SSL 証明書をインストールできます。

これらの証明書は、ロードバランサとクライアント間の通信を認証するために

ターゲット HTTPS プロキシによって使用されます

 

バックエンド サービス

リクエストを適切なバックエンドに振り分ける

 

 

細かな話はもっとあるのですが、詳細は、

 

HTTP(S) 負荷分散の設定  |  Compute Engine ドキュメント  |  Google Cloud

 

をご参照ください

 

Data Encryption from Nutanix bible(英語版)

ずいぶん空いてしまいましたが(githubへ乗り換えるか検討中)

メモ代わりの更新

 

Nutanix bible の 日本語版は だいぶ更新が滞ってしまっているので、

英語版から更新できるところを抜粋していきたいと思います。

 

まず、以下の項目から

--------------------------------------

Data Encryption

Nutanix provides data-at-rest encryption leveraging FIPS-140-2 Level-2 validated self-encrypting drives (SED) and an exernal key management server (KMS). Communication with the KMS leverages standard protocols including KMIP and TCG. Example KMS servers include Vormetric, SafeNet, etc.

------------------------------------

 

日本語訳してみます。

 

------------------------------------

Data 暗号化

Nutanix では、自己暗号化ドライブ(SED) と 外部の キー管理サーバ(KMS) が

認証された  FIPS-140-2 Level-2(FIPS = 連邦情報処理規格) を活用した

data-at-rest (保存データ) の暗号化を提供しています。

 

KMSとの通信では、KMIP や TCG を含む標準プロトコルを活用します。

KMSサーバの例には、Vormetric や SafeNet などが含まれます。

 

Data Encryption - Overview

 

 

SEDの暗号化は、ストレージデバイスを セキュア または 非セキュア状態に

することができる「データバンド」で分割することによって機能します。

 

Nutanixの場合、ブートパーティションと Nutanix Home パーティション

簡易に暗号化されています。

 

すべてのデータデバイスとバンドは レベル2 標準に対する  big keys で、

しっかりと暗号化されています。

 

クラスタが起動した際に、KMS サーバへ  ドライブのロックを解除するために、キーを取得するよう  要求します。

セキュリティを確保するために、キーはクラスタ上にキャッシュされません。

コールドブートや IPMIリセットの場合、ノードは、ドライブをロック解除するために

KMSサーバへコールバックする必要があります。

 

CVM をソフトリブートしても、これは 強制的に起こりえません。

 

---------------------------------------------

 

 

zeus_config in Nutanix log bundle

この記事は、Nutanix Advent Calendar 2017 の 14日目です。

#初参加!

 

adventar.org

 

 

以前にログバンドルを作成する方法は記載しましたが、

 

yu-k-syo2.hatenablog.com

 

ログバンドルは、

NCC-logs-<日付>-xxxx.xxxx.tar といったファイルが作成されます。

今回は、http://demo.nutanix.com の AHV 環境から採取したログを
解説いたします。

まず、上記 tar ファイルを展開すると 以下の ファイルが出来上がります。

 

f:id:Yu-K-Syo2:20171214083724p:plain

今回は、

NCC-logs-2017-10-19-3050639835602676466-1508438547
NCC-logs-2017-10-19-3050639835602676466-1508438547-CVM-31-meta

の圧縮されたファイルが存在しました。

 

次に、NCC-logs-2017-10-19-3050639835602676466-1508438547 側を展開します。

 

f:id:Yu-K-Syo2:20171214083828p:plain

 

 

先頭に IPアドレスがある gz ファイルは 各CVM の IP アドレスです。

 

次に、このファイルを展開します。


各CVM の gz ファイルには 以下のようにフォルダが分かれています。

 

f:id:Yu-K-Syo2:20171214083929p:plain

それぞれの解説ですが、

 

・ cvm_config => CVM の設定
・ cvm_logs => CVM 上の各プロセスのログ
・ fileserver_logs => FileServer用 ログ(AFS未使用なら不要)
・ hardware_logs => H/W 情報格納
・ hypervisor_cfg => HyperVisor の 構成情報が格納 ( ESXiならログなし )
・ hypervisor_logs => HyperVisor の ログ情報が格納 ( ESXiならログなし )
・ kernel_logs => dmesg,wtmp が格納
・ alerts.txt => アラート情報

 

となります。


その次に、

NCC-logs-2017-10-19-3050639835602676466-1508438547-CVM-31-meta

を展開します。

 

f:id:Yu-K-Syo2:20171214084058p:plain

それぞれの解説ですが、

 

・ cluster_config.tar => クラスタの構成情報
・ command.txt => ファイル作成時に使用したコマンド
・ hardware_info.txt => ハードウェア情報
ncc_info.txt => NCC の実行結果

 

となります。

 

今までの説明を簡易図にすると以下になります。

 

 

f:id:Yu-K-Syo2:20171214084142p:plain

 

では、次に個別の説明です。

 

細かな説明は長くなるので、今回は下記ファイル説明を行います。

 

○ cluster_config\cluster_config 配下

=> zeus_config.txt

以下のように クラスタの設定ファイルが格納されています。


****Log Collector Start time = 2017/10/19-07:35:41 PDT End time = 2017/10/19-11:35:41 PDT ****

zeus_config:
logical_timestamp: 442109
internal_subnet: "192.168.5.0/255.255.255.128"
external_subnet: "10.21.193.0/255.255.255.0"
storage_tier_list {
storage_tier_name: "SSD-PCIe"
random_io_priority: 9
sequential_io_priority: 9
storage_type: kPcieSSD
}
storage_tier_list {
storage_tier_name: "SSD-SATA"
random_io_priority: 8
sequential_io_priority: 8
storage_type: kSataSSD
}
storage_tier_list {
storage_tier_name: "DAS-SATA"
random_io_priority: 7
sequential_io_priority: 7
storage_type: kHDD
}
========= 略 ===============

 

そもそも、 zeus とは何でしょぅか?

 

Nutanix バイブルには 以下のように記載されています。

 

----

Zookeeper
主な役割: クラスタ構成マネージャー
説明: Apache ZookeeperをベースにしたZookeeperは、ホスト、IP、
状態など全てのクラスタ構成をストアします。本サービスは、
クラスタ内の3つのノードで稼動し、その内の1つがリーダーとして選出されます。
リーダーが全てのリクエストを受信し残りのサービスに転送します。
リーダーからのレスポンスが無い場合、新しいリーダーが自動的に選択されます。
Zookeeperは、Zeusと呼ばれるインターフェースを介してアクセスされます。

----

 

上記の通り、クラスタの構成情報は zookeeper -> zeus に 情報が
保存されていることになります。

 

以下、個別説明しましょう。

 

# でコメントしてます。

---

zeus_config:
logical_timestamp: 442109
internal_subnet: "192.168.5.0/255.255.255.128" # Internal IP
external_subnet: "10.21.193.0/255.255.255.0" # External IP
storage_tier_list {
storage_tier_name: "SSD-PCIe"
random_io_priority: 9
sequential_io_priority: 9
storage_type: kPcieSSD
}
storage_tier_list {
storage_tier_name: "SSD-SATA"
random_io_priority: 8
sequential_io_priority: 8
storage_type: kSataSSD
}
storage_tier_list {
storage_tier_name: "DAS-SATA"
random_io_priority: 7
sequential_io_priority: 7
storage_type: kHDD
}
disk_list { # 各ノード上の Disk の情報が格納 = node x disk 数
disk_id: 62
service_vm_id: 5
mount_path: "/home/nutanix/data/stargate-storage/disks/BTHC5456061U480MGN"
disk_size: 180351879372
statfs_disk_size: 326801059840
storage_tier: "SSD-SATA"
data_dir_sublevels: 2
data_dir_sublevel_dirs: 20
disk_location: 1 # ロケーション
contains_metadata: true
oplog_disk_size: 88376641536
ccache_disk_size: 21474836480
disk_serial_id: "BTHC5456061U480MGN" # シリアルナンバー
disk_uuid: "a8d9172c-5d09-41fa-990f-e67ef045d500" # disk の uuid
node_uuid: "beb4123f-afc9-408e-a789-d0f4e56526b5"
metadata_disk_reservation_bytes: 32212254720
26: "7cc1f58a-a06c-4e43-a5fa-8c8bfaebd0b5"
}
disk_list {
disk_id: 65
service_vm_id: 4
mount_path: "/home/nutanix/data/stargate-storage/disks/Z1X6HNDL"
disk_size: 1787128762572
statfs_disk_size: 1948852449280
storage_tier: "DAS-SATA"
data_dir_sublevels: 2
data_dir_sublevel_dirs: 20
disk_location: 3
disk_serial_id: "Z1X6HNDL"
disk_uuid: "8ce40c4d-3e9a-48e8-a1f4-cb0ff528aac4"
curator_disk_reservation_bytes: 64424509440
is_curator_primary: true
node_uuid: "a3775252-5d6c-4cd2-bd82-024db4004830"
26: "333d8978-7d64-4412-9c7d-1a01ea36ad27"
}
<略>
}
node_list { # 各 node の 情報が格納 => node 数(今回なら3)
service_vm_id: 4
service_vm_external_ip: "10.21.193.29"
node_status: kNormal
hypervisor_key: "10.21.193.25" 
management_server_name: "10.21.193.25"  # HyperVisor IP
cassandra_token_id: "FV0000006TbNVqegqHHXGSFBY5QtRVda7obAzNfXbhm7Hv6ajSe2PRJiZFPC"
hypervisor {
address_list: "10.21.193.25" # Hypervisor IP
}
ipmi {
address_list: "10.21.193.33" # IPMI の IP
}
zookeeper_myid: 1
uuid: "a3775252-5d6c-4cd2-bd82-024db4004830"
rackable_unit_id: 34
node_position: 1 # node の ポジション
maintenance_mode: false
reason_for_maintenance_mode_list: "Firmware upgrade"
reason_for_maintenance_mode_list: "Hypervisor upgrade"
cassandra_status: kNormalMode
software_version: "el6-release-euphrates-5.1.2-stable-e429c7210f0786ed677edec3eef7e52f4d83881a"
node_serial: "ZM15CS043320"
hardware_config: "/appliance/physical/hardware_configs/f21afbc8fb93e31494ca2e65f2521396"
management_server_id: 64
cassandra_status_history {
cassandra_status: kMetadataRepairRequired
state_change_source: kDetachDueToFrequentRestarts
svm_id_source_of_status_change: 4
cassandra_status_change_timestamp: 1497539042662128
}
cassandra_status_history {
cassandra_status: kMetadataRepairDone
state_change_source: kDynamicRingChanger
svm_id_source_of_status_change: 5
cassandra_status_change_timestamp: 1497542096381603
}
cassandra_status_history {
cassandra_status: kNormalMode
state_change_source: kCassandraMonitor
svm_id_source_of_status_change: 4
cassandra_status_change_timestamp: 1497542099300276
cassandra_token_id: "FV0000006TbNVqegqHHXGSFBY5QtRVda7obAzNfXbhm7Hv6ajSe2PRJiZFPC"
}
acropolis_status {
node_state: kAcropolisNormal
logical_timestamp: 27
}
last_known_metadata_disk_id: 67
cassandra_compaction_pending: false
cluster_uuid: "00052fdc-bb27-00ad-2a56-0cc47ac0eaf2"
rackable_unit_uuid: "84a2fac6-b6d6-4733-b9a5-a6786ab9ce4d"
management_server_uuid: "5e963224-cbc6-475b-8ba4-b12a28ed9869"
cassandra_schema_timestamp: 15
controller_vm_backplane_ip: "10.21.193.29"
cvm_resource_state {
memory_mb: 32175
}
39: "333d8978-7d64-4412-9c7d-1a01ea36ad27"
}
<略>
}
storage_pool_list { # ストレージプールの情報です。
storage_pool_name: "sp-demo"
storage_pool_id: 8
disk_id: 61213623
disk_id: 65
disk_id: 67
disk_id: 18247953
disk_id: 309833743
disk_id: 42237310
disk_id: 61213624
disk_id: 62
disk_id: 61213625
ilm_down_migrate_pct_threshold: 75
total_implicit_reserved_capacity: 7670811590656
storage_pool_uuid: "d22c1983-5928-459c-8a55-3b94b07b46a2"
disk_uuid: "a3cf2bcd-d4fb-408a-91ce-32383a194f98"
disk_uuid: "56df377e-8c6a-4a82-a0d6-4305dc890a10"
disk_uuid: "3ee76099-459f-4f12-b417-2addd3b37963"
disk_uuid: "62d3eccb-24c6-47c1-bb3e-b093932f9fdf"
disk_uuid: "a8d9172c-5d09-41fa-990f-e67ef045d500"
disk_uuid: "4305af14-fc33-477e-af06-872e78c6fca6"
disk_uuid: "5cf9dc39-653a-4664-ad13-e25ac2f05a34"
disk_uuid: "05cb2217-e8cb-4d59-9107-dd6cf22257d8"
disk_uuid: "8ce40c4d-3e9a-48e8-a1f4-cb0ff528aac4"
}
container_list { # コンテナ情報。
container_name: "NTNX-AHV-PROD"
container_id: 121883
storage_pool_id: 8
params {
replication_factor: 2     # コンテナのRF値
compression_type: kLow
random_io_tier_preference: "SSD-PCIe"
random_io_tier_preference: "SSD-SATA"
random_io_tier_preference: "DAS-SATA"
sequential_io_tier_preference: "SSD-PCIe"
sequential_io_tier_preference: "SSD-SATA"
sequential_io_tier_preference: "DAS-SATA"
total_explicit_reserved_capacity: 0
max_capacity: 11338003414323
ilm_down_migrate_time_secs: 1800
ilm_down_migrate_time_secs: 1800
ilm_down_migrate_time_secs: 1800
oplog_params {
replication_factor: 2
num_stripes: 1
need_sync: false
}
nfs_subnet_whitelist: "10.21.194.0/255.255.255.128,10.20.26.150/255.255.255.0"
data_contraction_policy {
dedup_compress_delay_secs: 0
on_disk_dedup_policy: kOff
}
fingerprint_on_write: true
advertised_capacity_bytes: 4398046511104
}
container_uuid: "a0bb8b93-ba8a-4ed3-8b54-f2eb201acd3a"
storage_pool_uuid: "d22c1983-5928-459c-8a55-3b94b07b46a2"
fsid: 3
epoch: 0
}
<略>
management_server_list {
management_server_name: "127.0.0.1"
management_server_type: kAcropolis
management_server_id: 33
management_server_uuid: "b658e0b3-6cdb-4ff3-9562-bdc755177dab"
}
management_server_list {
management_server_name: "10.21.193.27"    # HyperVisor の IPアドレス
access_url: "qemu+ssh://10.21.193.27/system"
management_server_type: kKvm     # KVM = AHV 構成
management_server_id: 58
parent_management_server_id: 33
management_server_uuid: "aa64ed4c-935e-41cf-852d-14141b8137d3"
parent_management_server_uuid: "b658e0b3-6cdb-4ff3-9562-bdc755177dab"
management_server_version: "el6.nutanix.20160925.84"
}
<略>
}
remote_site_list {
remote_name: "esx"
remote_cerebro_ip_list: "10.21.194.37"
remote_cerebro_port_list: 2020
enable_proxy: false
local_vstore_name: "test1234"
remote_vstore_name: "test0101"
cluster_id: 6346993287861168729
cluster_incarnation_id: 1489705096486047
compression_algorithm: kSnappy
compression_type: kLow
external_subnet: "10.21.194.0/255.255.255.0"
capabilities {
backup: false
disaster_recovery: true
supports_deduped_extents: true
supports_vsphere: true
supports_hyperv: false
supports_kvm: false
supports_vstore_stretching: true
supports_on_wire_sparse_extents: true
max_virtual_hardware_version {
vsphere_max_virtual_hardware_version: 11
}
supports_vstore_resolution: true
supports_diff_vblocks: true
cross_hypervisor_dr_capabilities_bitmap: 1152974281164980227
cerebro_features_bitmap: 108031
file_level_restore_capabilities_bitmap: 4194311
cluster_operation_mode: kNormal
cerebro_receive_rpc_timeout_msecs: -1
cluster_properties_bitmap: 0
minimum_supported_rpo_secs: 3600
}
remote_site_uuid: "00054ae0-ff18-9c9f-5815-0cc47ac0ea59"
network_mapping_uuid: "856996f3-4a86-4f58-b381-3967de451b2e"
stargate_version: 320
bandwidth_policy_uuid: "98779f3b-b592-4450-a653-5d192c004d84"
rackable_unit_model_names: "NX-1065-G4"
is_network_mapping_present_for_local_site: true
cluster_external_data_services_ip: "10.21.194.38"
file_server_capabilities {
bitmap: 6
}
}
cluster_incarnation_id: 1459999962759341
cluster_id: 3050639835602676466
cluster_name: "demo-ahv"     # クラスタ
aegis {
remote_support {
value: true
until_time_usecs: 1506700553989000
}
email_alerts {
value: true
until_time_usecs: 0
}
smtp_server {    # SMTP サーバ名
address_list: "nutanix-com.mail.protection.outlook.com"
port: 25
}
smtp_server_type: kPlain
verbosity: kBasicPlusCoreDump
auto_support_config {
email_asups {
value: true
until_time_usecs: 0
}
send_email_asups_externally: true
aos_version: "danube-4.7.3.1-stable"
last_login_workflow_time_msecs: 1483703765628
remind_later: false
}
send_email_alerts_externally: true
send_alert_email_digest: true
}
vdisk_list_in_pithos: true
default_gateway_ip: "10.20.193.1"   # Gateway
ntp_server_list: "pool.ntp.org"
name_server_ip_list: "10.21.253.10"    # NTP
name_server_ip_list: "10.21.253.11"
rackable_unit_list {
rackable_unit_id: 34
rackable_unit_serial: "16AP65110008"
rackable_unit_model: kUseLayout
rackable_unit_model_name: "NX-1065-G4"    # モデル名
rackable_unit_uuid: "84a2fac6-b6d6-4733-b9a5-a6786ab9ce4d"
}
snmp_info {
enabled: true
user_list {
username: "test"
auth_type: kSHA
auth_key: "64515144165C47134659"
priv_type: kAES
priv_key: "64515144165C47134659"
}
transport_list {
protocol: kUDP
port: 161
}
transport_list {
protocol: kTCP
port: 161
}
}
cassandra_schema_version: "el6-release-euphrates-5.1.2-stable-e429c7210f0786ed677edec3eef7e52f4d83881a"
auth_config {
auth_type_list: kLOCAL
auth_type_list: kDIRECTORY_SERVICE
directory_list {
directory_type: kACTIVE_DIRECTORY
connection_type: kLDAP
directory_url {
id_str: "demo-dc"
access_url: "ldap://10.21.193.20:389"
}
domain: "demo.nutanix.com"
group_search_type: kRECURSIVE
uuid: "8b63a85a-e13d-49cc-a435-a626f4b61548"
enabled_in_ssp: true
service_account {
username: "ssp-service-acct@demo.nutanix.com"
encrypted_password: "NDc4MzQ3MDIyMzI0NTI0OQ8UB6VL8mXjP7b457tcrKE="
}
}
directory_list {
directory_type: kACTIVE_DIRECTORY
connection_type: kLDAP
directory_url {
id_str: "TOC"
access_url: "ldap://10.0.73.1:389"
}
domain: "TOC.com.local"
uuid: "6495321e-2ca3-4bb5-a64c-b58698c094c6"
}
}
vstore_list {
vstore_id: 121883
vstore_name: "NTNX-AHV-PROD"
container_id: 121883
vstore_uuid: "a0bb8b93-ba8a-4ed3-8b54-f2eb201acd3a"
container_uuid: "a0bb8b93-ba8a-4ed3-8b54-f2eb201acd3a"
}
vstore_list {
vstore_id: 35405285
vstore_name: "NutanixManagementShare"
container_id: 35405285
vstore_uuid: "03c44825-1cd0-427b-a421-9397a5704b73"
container_uuid: "03c44825-1cd0-427b-a421-9397a5704b73"
}
release_version: "el6-release-euphrates-5.1.2-stable-e429c7210f0786ed677edec3eef7e52f4d83881a"
ssh_key_list {
key_id: "beb4123f-afc9-408e-a789-d0f4e56526b5"
pub_key: "ssh-rsa 
<略>
cluster_content_cache_fingerprint_pct: 100
disk_tombstone_list: "BTHC5456069N480MGN"
disk_tombstone_list: "Z1X6KNED"
disk_tombstone_list: "Z1X6JM97"
cluster_external_ip: "10.21.193.37"   
cluster_fault_tolerance_state {
current_max_fault_tolerance: 1
desired_max_fault_tolerance: 1
}
domain_fault_tolerance_state {  # イベント
domains {
domain_type: kNode
components {
component_type: kZookeeperInstances
max_faults_tolerated: 1
last_update_secs: 1507215177
tolerance_details_message {
message_id: "Zookeeper can tolerate 1 node failure(s)"
}
}
components {
component_type: kCassandraRing
max_faults_tolerated: 1
last_update_secs: 1507215209
tolerance_details_message {
message_id: "All metadata ring partitions are fault tolerant"
}
}
components {
component_type: kStargateHealth
max_faults_tolerated: 1
last_update_secs: 1508438178
tolerance_details_message {
message_id: "Based on stargate health the cluster can tolerate a maximum of 1 node failure(s)"
}
}
<略>
}
shadow_clones_enabled: true
password_remote_login_enabled: true
stargate_version: 320
cluster_functions: 1
cluster_uuid: "00052fdc-bb27-00ad-2a56-0cc47ac0eaf2"
timezone: "America/Los_Angeles"    # タイムゾーン
disable_on_disk_dedup: true
extended_nfs_fhandle_enabled: true
block_iscsi_target_ips {
logical_timestamp: 5
}
curator_scan_info {
partial_scan_execution_id: 42930
full_scan_execution_id: 42905
}
acropolis_ha_config {
failover_enabled: true
num_host_failures_to_tolerate: 0
logical_timestamp: 146
ha_state: kAcropolisHABestEffort
reservation_type: kAcropolisHANoReservations
reservation_type_override: false
removed_node_locality_cleared: true
}
ncc_version: "ncc-2.2.6"     # NCC バージョン
cvm_security_compliance_config {
schedule: kDaily
aide: false
core: false
high_strength_password: false
banner: false
snmp_v3_only: false
}
hypervisor_security_compliance_config {
schedule: kDaily
aide: false
core: false
high_strength_password: false
banner: false
}
cluster_external_data_services_ip: "10.21.193.38"
disable_degraded_node_monitoring: true
cluster_operation_mode: kNormal
common_criteria_mode: false
iscsi_config {
external_clients_enabled: true
iscsi_client_uuid_fix_done: true
}
curator_stargate_protocol_config {
current_version: 1
desired_version: 1
enable_dedup_extents_two_phase_deletion: true
}
initialized_dedup_extents_two_phase_deletion: true
management_share_container_id: 35405285
default_ssp_container_id: 53603063


================

 

数が多いのですべての項目は説明しきれませんが、
上記のように zeus_config.txt を参照することで
クラスタ全体の構成情報を把握することができます。

 

ぜひ、Nutanixのスキルを伸ばしたい要望がありましたら、
ログファイルを採取し眺めてみることをお勧めします。

 

※ 今回は、zeus_config.txt だけだったので次回以降でも
ログバンドル内のファイルを説明します。

---

 

明日は、vExpert であり Nutanix NTC でもある 

SH Hwang(@yueisu913)さん | Twitter

さんの登場です。AFS も楽しそうなので期待です!!

 

 

 

demo.nutanix.comについて

今回のブログは小ネタです。

http://demo.nutanix.com

というサイトでNutanix の Prism画面を触れることは
ご存知かと思いますが、

 

(1) 過去には、AHV,ESXi,Hyper-V,Prism のみが触れる状態でしたが、現在は、XCシリーズ(DELL) と UCS(CISCO) の 環境も触れるように改変されております。

       f:id:Yu-K-Syo2:20171208214732p:image

 

(2) 次に 好きな HyperVisor へログインしてみてください。

f:id:Yu-K-Syo2:20171208214920p:image



Prism 画面で、マウス右クリックから 「ページのソースを表示」 or 「検証」を選ぶと

f:id:Yu-K-Syo2:20171208215004p:image


Nutanix UI Team からメッセージがあります。
このような遊び心も Nutanix 社内のみなさまが楽しんで仕事している部分かもしれません。

 

GUIで作成したログバンドルの格納先

今回は、GUI で作成したファイルがどこに格納されるのかを確認してみます。

 

今回は、CVM 上での 作業が 多いので

分かりづらければ、ご指摘いただければ。

 

※ CVM へは CVM の IP に対して ssh ログイン

することでログイン可能になります。

 

まず、バージョンを確認していきましょう

今回の環境の AOS のバージョンは以下のコマンドで確認可能です。

 

$ ncli cluster version

Cluster Version : euphrates-5.0.3-stable

より 5.0.3 が分かります。


次に、NCC の バージョンを確認しましょう。

NCC バージョンは 以下のコマンドで確認可能です。

 

$ ncc --version
3.0.3.2-16e3fe75

3.0.3.2 ということがわかりました。


AOS : 5.0.3
NCC : 3.0.3.2

でした。

 

以下、今回の本題です。


前回の記事の方法で GUI 上から LOG Bundle の作成方法を説明しましたが、
クラスタIP を経由して GUI から 作成したものになります。

では、クラスタIPを経由した場合、どの CVM 上にファイルは作成されるのでしょうか?

 f:id:Yu-K-Syo2:20171113214214p:image

 


1つ目の ログファイルの作成ができました。

このとき、CVM 上では、以下の場所に作成されていました。

 

※ CVM へ ログイン

 f:id:Yu-K-Syo2:20171113221926p:image

 

※ 初回だったからなのか /home/nutanix/data 配下でした。

 

なぜ、この CVM(10.101.2.92) 上 だったのでしょうか?

実はこの CVM は Acropolis Master(つまりClusterIPを持つCVM) になります。

 

Master の確認方法は、以下のコマンドで確認可能です。

 

allssh "links -dump http://0:2030 | grep Master"

 f:id:Yu-K-Syo2:20171113221951p:image

※ allssh コマンドは すべての CVM上で同一のコマンドを実行します。
詳細は以下が参考になりました。

<参考> Nutanix CVM にある allssh の正体。
http://blog.ntnx.jp/entry/2017/05/04/031912

 

このCVM の data 配下に作成されました。

では、もうひとつ ログバンドルを作成しましょう。

f:id:Yu-K-Syo2:20171113214109p:image
同じところに 2つ目の ログバンドル ができました。

f:id:Yu-K-Syo2:20171113222021p:image

この時点で一旦評価を終えて、数日たって、再度ログバンドルの格納先を確認してみると、
格納場所が以下に変わっていました。

 

* /home/nutanix/data/log_collector 配下


f:id:Yu-K-Syo2:20171113222051p:image

どこかの処理の中で data 配下の ログバンドル を log_collector 配下 へ 移動させる処理を行っているようでした。

 

では、もうひとつ作成してみましょう。

どうなるでしょうか?

f:id:Yu-K-Syo2:20171113214631p:image 

GUI 上で 一番最初の ファイルの リンクが消え、新しいファイルのリンクが作成されています。

 

つまり、NCC のログ は GUI 上で 最新 2個 というかたちで制限されています!

 

では、3個目のログバンドルは何処に格納されたのでしょうか?
1個目のログは本当になくなったのでしょうか?

 

CVM 上から 以下のコマンドで確認できます。

 

$ allssh sudo find / -name NCC-log*

 

※ 今回、テスト環境なので find / を実施しています。
本番環境で実施する場合は、負荷が高くなる可能性がありますのでやめておくことをお勧めします。
f:id:Yu-K-Syo2:20171113222123p:image

以前のログは残っており 別の CVM 上で ログバンドルが格納されています。

 

※ Acropolis Master 以外の CVM で ログバンドルが作成されたので、CVM の中に 2つ以上 NCC の ログバンドルが存在する場合は、別の CVM 上で作成する 処理があるようです。

以下、今回の評価のまとめです。

 

● 基本的には、GUI上 で採取したログバンドルは最新 2つのみ。
    新たに ログバンドル作成した段階で一番古いログバンドルのリンクは消える。

● ログバンドル作成時 CVM の 容量を圧迫しないように、同一の CVM で 2つ以上のファイルを作成せずに 別の CVM 上にファイルを保持する。
※ ファイルを作っても容量圧迫にはつながらないようですのでご安心

 

● ログバンドルは、どこかの CVM の

/home/nutanix/data/log_collector 配下に格納

です。何か気になる点があれば追記いたします。

 

 

Nutanix ログバンドルの採取方法

障害発生時、サポートからログバンドルの採取を
依頼される場合があると思います。

 

以前のバージョンは、CVM へ SSH ログインして
ログを採取する必要がありましたが、

Version 5.0 以降からGUI 上でもログを

採取することができるようになりました。

 

今回、https://demo.nutanix.com から

AHV 環境にログインした状態での
ログバンドルを採取しています。

 

https://demo.nutanix.comGUI上の操作

イメージを確認できるサイトになります。

Nutanixを触る予定がある方は

ぜひアクセスしてみてください。

まず、今回の環境を確認するために現在の

バージョンを確認します。

バージョンを確認するには、右側のギアアイコン

をクリックし、About Nutanix を選択します。

 

f:id:Yu-K-Syo2:20171105205908p:image


About Nutanix の画面が起動しますので、

今回のバージョンは、5.1.2 であることが

確認できます。

 

f:id:Yu-K-Syo2:20171105205932p:image

 

次にログを採取します。

ログですが、左上部にあるメニューから、

Health を選択します。

 

 f:id:Yu-K-Syo2:20171105210138p:image

 

Health の画面で、右側のメニューから Log Collector を選択します。

 

f:id:Yu-K-Syo2:20171105210203p:image


Log Collector の画面で、ログを採取する期間を

選択して Run Now を 実施します。

 

 f:id:Yu-K-Syo2:20171105210518p:image

 

※ 障害発生した時間のログを採取する必要が

ありますが、デフォルト(=4時間) 以上だと

かなりログが大きくなりますので
通常はデフォルトのままでよいと思います。

Home 画面に戻ります。
TASK の V マークをクリックすることで

現在動作しているタスクが確認可能です。

※ 今回の環境では大体、10分ほどでログの

採取ができました。

 

f:id:Yu-K-Syo2:20171105210505p:image

 

Log Collector の TASK が 100% になったことを

確認したので、一番下にある View All Task を

選択します。

 

f:id:Yu-K-Syo2:20171105210352p:image


TASK の一覧が表示されます。
※ 8分って表示されてますね(^^;

 

f:id:Yu-K-Syo2:20171105210621p:image


Succeeded の箇所がクリックできるように

なっています。

 

ここをクリックすることにより、ログバンドルをローカルPC 上へ 持ってくることが可能となります。

 

※ デフォルト設定でしたが、容量は 369MB でした。

 

ログの内容については、また別の機会に

解説いたします。