Professional Cloud Architect に挑戦しよう！！
またもお久しぶりです。
2018/09/19 に Google Cloud の Professional Cloud Architect に合格しました。
現在、急激な伸びを見せる、Google Cloud について資格を保有することは
自らのキャリアアップについても重要なことだと考えます。
みなさまに、もっと、資格を挑戦してもらえるように、このブログを
書きたいと考えております。
（１）Professional Cloud Architect とは。。。
上記リンクでは、以下のように記載されております。
--------------
Google Cloud の技術を組織が活用するために必要なクラウド アーキテクチャと Google Cloud Platform に関する専門的な知識を有することを認められ、ビジネス目標を実現するための堅牢かつ安全でスケーラブルな高可用性の動的ソリューションを設計、開発、管理できる者
--------------
つまり、Google Cloud を用いてお客様のシステムを構築、運用できる
スキルをもった人物。となります。
なお、蛇足ですが、機械学習などのスキルを有する
Professional Data Engineer
や、Google Cloud で 一般的なタスクが実施できる
Associate Cloud Engineer
といった資格があります。
（２）試験のお値段は？
200ドルとなります。(しっかり勉強し、円高のときに受験しましょう)
（３）会場は？
当方は、秋葉原で受験しました。都内であれば、ほかには池袋や八重洲などが
あります。残念ながら西東京にはないので、西側に住む方や地方に住む方は
受験の際には移動が大変になるかもしれません。。。。
早く改善してもらえればと願います。。。
（４）試験はどんなかんじなの？
以下に具体的な内容があります。
重要なのはケーススタディです。
以下の 4社が Google Cloud へビジネスを移行する際に、どのように
したら良いか。。。が問題となります。
後述しますが、まずは、Google Cloud では どのような製品があるのかを
理解すること。次に、上記のケースにおいて、Google Cloud の製品を
どのように利用すれば、お客様の成功を実現できるか？ がカギとなります。
そのことを頭にいれて、ケーススタディを見ていくと良いでしょう。
（５）勉強方法
では、具体的な勉強方法についてです。
（５_1 ）Google Cloud の 製品を覚えよう
本ページに記載されてある Google Cloud の 製品については、理解しておいてください。
ただ、製品だけを理解するのではなく、どのように使用されるか？またその際に
どのような注意点があるか？を理解することが重要です。
たとえば、BigQuary については、導入事例が存在します
BigQuery - アナリティクス データ ウェアハウス | BigQuery | Google Cloud
ソリューションの項目まで学習して、製品についての理解を深めましょう。
ただし、製品一覧にある、AI と 機械学習 は範囲外 です。
深く勉強する必要は無いと考えてますが(Data Engineer で学習する)
100%出ないとはいいきれないので、概要レベルは理解しておきましょう。
（５_2）Google の Cloud OnAir をみよう。
毎週、Google Cloud の カスタマサポートエンジニアの方々が、Google Cloud の
製品について、説明してくれています。
それぞれ面白いので、全部見てもらえるのが一番なのですが、中でもテストで
役立つと感じたのは、 7-9月期に行われた 夏季集中講座の内容です。
ここで製品を理解した後にテストに挑むことをお勧めいたします。
（５_3）Google Cloud .NEXT の内容を見よう。
Google Cloud Japan の Youtube の ページに 先日行われた Google Cloud .NEXT Tokyo の動画がアップロードされています。
こちらも時間があるときに、鑑賞することをお勧めします。
トップエンジニアの説明はやはりわかりやすいものです。
（５_4）Google Cloud の プロダクトで アーキテクチャ図を作れるようになろう。
データがどのように入力され、どのように加工され、どのように出力されるのか
その一連の流れを自分の中で消化することが重要です。
製品の説明だけでもある程度把握は出来ますが、正しいアーキテクチャ図を
知りたくなると思います。
当方は以下の資料を基に学習しました。
英語の資料になりますが、このようなお客様では、このようにシステム全体を作成
できる。 といった内容がアーキテクチャ図として記載されておりますので、
Google Cloud の理解に非常に役立つものでした。
さて、時間がなくなったので、さらに細かな点は次回に！
早めに更新します！！
Nutanix .NEXT での新機能整理
Nutanix .NEXT に参加しましたが、そこで発表された新機能について
簡単にまとめておきます
情報は原文の投稿時のものですので、今後の製品情報と
差異が生じている場合があります。
■ Nutanix Era
<機能>
⇒ Nutanix の機能で ワンクリックで データベースを
プロビジョニング、コピー、特定時点でのリストアを可能にする。
⇒ データベースの ワンタッチ・タイムマシン
⇒ 簡単にスナップショットを作成する。
⇒ ワンクリックデータベースクローン/リフレッシュ
⇒ データベースのクローン処理や特定時点へのリストア処理をワンクリックで実施
<対応>
⇒ Oracle と Postgres SQL
⇒ 今後、Microsoft SQL Server や MySQL も対応予定
<リリース>
⇒ 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) 負荷分散イメージについてです。
負荷分散は下記のように実施されます。
説明が足りていない部分は多いですが、大きな流れでこのとおりです。
なお、HTTPS の場合は以下の条件がありますので、ご確認ください。
１．ターゲット HTTP プロキシではなくターゲット HTTPS プロキシを使用します。
２．ロードバランサのターゲット 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 などが含まれます。
SEDの暗号化は、ストレージデバイスを セキュア または 非セキュア状態に
することができる「データバンド」で分割することによって機能します。
Nutanixの場合、ブートパーティションと Nutanix Home パーティションは
簡易に暗号化されています。
すべてのデータデバイスとバンドは レベル2 標準に対する big keys で、
しっかりと暗号化されています。
クラスタが起動した際に、KMS サーバへ ドライブのロックを解除するために、キーを取得するよう 要求します。
セキュリティを確保するために、キーはクラスタ上にキャッシュされません。
コールドブートや IPMIリセットの場合、ノードは、ドライブをロック解除するために
KMSサーバへコールバックする必要があります。
CVM をソフトリブートしても、これは 強制的に起こりえません。
---------------------------------------------
zeus_config in Nutanix log bundle
この記事は、Nutanix Advent Calendar 2017 の 14日目です。
#初参加！
以前にログバンドルを作成する方法は記載しましたが、
ログバンドルは、
NCC-logs-<日付>-xxxx.xxxx.tar といったファイルが作成されます。
今回は、http://demo.nutanix.com の AHV 環境から採取したログを
解説いたします。
まず、上記 tar ファイルを展開すると 以下の ファイルが出来上がります。
今回は、
NCC-logs-2017-10-19-3050639835602676466-1508438547
NCC-logs-2017-10-19-3050639835602676466-1508438547-CVM-31-meta
の圧縮されたファイルが存在しました。
次に、NCC-logs-2017-10-19-3050639835602676466-1508438547 側を展開します。
先頭に IPアドレスがある gz ファイルは 各CVM の IP アドレスです。
次に、このファイルを展開します。
各CVM の gz ファイルには 以下のようにフォルダが分かれています。
それぞれの解説ですが、
・ 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
を展開します。
それぞれの解説ですが、
・ cluster_config.tar => クラスタの構成情報
・ command.txt => ファイル作成時に使用したコマンド
・ hardware_info.txt => ハードウェア情報
・ ncc_info.txt => NCC の実行結果
となります。
今までの説明を簡易図にすると以下になります。
では、次に個別の説明です。
細かな説明は長くなるので、今回は下記ファイル説明を行います。
○ 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について
今回のブログは小ネタです。
というサイトでNutanix の Prism画面を触れることは
ご存知かと思いますが、
(1) 過去には、AHV,ESXi,Hyper-V,Prism のみが触れる状態でしたが、現在は、XCシリーズ(DELL) と UCS(CISCO) の 環境も触れるように改変されております。
(2) 次に 好きな HyperVisor へログインしてみてください。
Prism 画面で、マウス右クリックから 「ページのソースを表示」 or 「検証」を選ぶと
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 上にファイルは作成されるのでしょうか？
1つ目の ログファイルの作成ができました。
このとき、CVM 上では、以下の場所に作成されていました。
※ CVM へ ログイン
※ 初回だったからなのか /home/nutanix/data 配下でした。
なぜ、この CVM(10.101.2.92) 上 だったのでしょうか？
実はこの CVM は Acropolis Master(つまりClusterIPを持つCVM) になります。
Master の確認方法は、以下のコマンドで確認可能です。
allssh "links -dump http://0:2030 | grep Master"
※ allssh コマンドは すべての CVM上で同一のコマンドを実行します。
詳細は以下が参考になりました。
<参考> Nutanix CVM にある allssh の正体。
http://blog.ntnx.jp/entry/2017/05/04/031912
このCVM の data 配下に作成されました。
では、もうひとつ ログバンドルを作成しましょう。
同じところに 2つ目の ログバンドル ができました。
この時点で一旦評価を終えて、数日たって、再度ログバンドルの格納先を確認してみると、
格納場所が以下に変わっていました。
* /home/nutanix/data/log_collector 配下
どこかの処理の中で data 配下の ログバンドル を log_collector 配下 へ 移動させる処理を行っているようでした。
では、もうひとつ作成してみましょう。
どうなるでしょうか？
GUI 上で 一番最初の ファイルの リンクが消え、新しいファイルのリンクが作成されています。
つまり、NCC のログ は GUI 上で 最新 2個 というかたちで制限されています！
では、3個目のログバンドルは何処に格納されたのでしょうか？
1個目のログは本当になくなったのでしょうか？
CVM 上から 以下のコマンドで確認できます。
$ allssh sudo find / -name NCC-log*
※ 今回、テスト環境なので find / を実施しています。
本番環境で実施する場合は、負荷が高くなる可能性がありますのでやめておくことをお勧めします。
以前のログは残っており 別の CVM 上で ログバンドルが格納されています。
※ Acropolis Master 以外の CVM で ログバンドルが作成されたので、CVM の中に 2つ以上 NCC の ログバンドルが存在する場合は、別の CVM 上で作成する 処理があるようです。
以下、今回の評価のまとめです。
● 基本的には、GUI上 で採取したログバンドルは最新 2つのみ。
新たに ログバンドル作成した段階で一番古いログバンドルのリンクは消える。
● ログバンドル作成時 CVM の 容量を圧迫しないように、同一の CVM で 2つ以上のファイルを作成せずに 別の CVM 上にファイルを保持する。
※ ファイルを作っても容量圧迫にはつながらないようですのでご安心
● ログバンドルは、どこかの CVM の
/home/nutanix/data/log_collector 配下に格納
です。何か気になる点があれば追記いたします。
