Nutanix AHVの計画・設計・構築・運用 Overview
•
5 likes•2,824 views
2019/2/28開催 Nutanix Meetup #37の発表資料です。 NutanixのHCI環境の運用効率やROIを最大化できる、自社製ハイパーバイザー「AHV」について、検討段階から実際に導入した後までの全体像をざっくりイメージできるようになることを目的としています。 あくまでOverviewなので、すべては網羅していません。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Nutanix AHVの計画・設計・構築・運用 Overview
Similar to Nutanix AHVの計画・設計・構築・運用 Overview (17)
More from Satoshi Shimazaki
More from Satoshi Shimazaki (20)
Nutanix AHVの計画・設計・構築・運用 Overview
- 1. の計画・設計・構築・運用
- 2. • 本資料は、 年 月末時点における弊社の一般的な製品機能の方向性に関する概要を説明するものです。 • 本資料は情報提供を唯一の目的とするものであり、法律的またはその他の指導や助言を意図したものではなく、 いかなる契約にも用いることはできません。 • 本資料に含まれている情報については、完全性と正確性を期するよう努力しましたが、「現状」で提供され、 明示的または暗示的に関わらず、いかなる保証も伴わないものとします。 • 本資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害か生した場合も、 及びニュータニックス・ジャパン合同会社は責任を負わないものとします。 • 本資料で提供する情報やマテリアル、機能を確実に提供することを確約するものではありません。 弊社製品に関して記載されている機能の開発、リリースおよひ時期については、弊社の裁量により決定されます。
- 3. この資料の位置づけ • の 環境の運用効率や を最大化できる 自社製ハイパーバイザー「 」について 検討段階から実際に導入した後までの全体像を ざっくりイメージできるようになることを 目的としています • あくまで なので、すべては網羅していません • に限らない 全体に共通する話は省きがちです • いつになく文字が多いです • 当日はデモをお見せしましたが、 当資料には含まれませんのでご了承ください。
- 5. とは
- 6. とは • による ユーザーのためのハイパーバイザー • オープンソース界のデファクトスタンダードな ハイパーバイザーである がコア • にとって有用な機能をひととおり揃え、 多くのユースケースで使う機能はデフォルトで有効に • にとって不要な機能は削る
- 7. 向けに開発された主な機能 • 管理 – • クラスタ – – 的なもの – ポリシー – • – 高速化 – – – • ネットワーク – 分散スイッチ – アドレス管理 – 物理スイッチ接続の可視化 – マイクロセグメンテーション • バックアップ – 異種ハイパーバイザー間 • 移行ツール – 旧
- 8. かなり使われている • 世界最大の ユーザー 台以上 すべて • 年、米国連邦政府導入の が 年 ～ 月 日本も 同じくらい これ以上！
- 9. が選ばれる理由 • 追加ライセンス費用なし • 必要十分な機能セット • 運用負荷の低減 • 学習コストの抑制 • ワンストップサポート • 既存環境からの移行性
- 10. おススメの資料 • から参照 – – – – • 英語が苦手な場合には の翻訳機能で ※個人の意見です – 誤訳個所は明らかに文脈がおかしくなるので概ね気づく – 怪しいと思ったら原文に戻る • バイブル パート •
- 11. 計画 できること、できないこと
- 12. 対応ゲスト 時点 • 提供元のサポートが切れた は、基本的に対象外 動かないとは言ってない • 主なサポート対象 – ～ – – • 詳細なバージョン等は で確認 –
- 13. 既存システムからの移行 • 旧称 – 移行ツール – を自動インストール – 差分転送および カットオーバー処理による 最低限のダウンタイム – 以降に対応 – は • 手動マイグレーション – でインポート – は事前に手動インス トールする必要あり – 予めゲスト を止めてから転送 するためダウンタイムは大きめ – に対応
- 14. のライフサイクル • 使用する のバージョンによって 対応する のバージョンが決まる 対 ではない • 導入＆アップグレードする前には 必ず と を必ず確認する – – – と同様に、 の を使用 – と併せて、年に 回程度の間隔で更新するのが現実的
- 15. 5.10.X LTS 【参考】 のサポートライフサイクル 5.5.X LTS 5.6.X STS 5.8.X STS 5.9.X STS ?.?.X STS 15 Months Maintenance 6 Months Support 3 Months Support 3 Months Maintenance 3 Months • か月毎のリリース ✓ サポートが か月間 ✓ リリース時点で開発済みの機能を迅速に取込む • 年毎のリリース ✓ サポートが か月間 ✓ ひとつ前までの に含まれる機能を取込む ✓ には大幅な変更を 基本的に 盛り込まない • バージョンアップ時の と 間での行き来は自由 ✓ 従来通りバージョンダウンはできないので、 から へ移る際にはサポート期間を認識したうえで判断すること
- 16. バックアップ＆ • 標準でも高機能 – 単位ローカル＆リモートスナップ、ディザスターリカバリー、 連携、セルフサービスリストア、 – では最短 分 ※ 分 開発中 • のシステム外に保管したい場合には 製品 – 等
- 17. • 停電発生時などの安全なシャットダウンに必要 • シャットダウンの順序がポイント – 構成だと ゲスト →サーバー→ストレージ の順 – だと ゲスト → → →サーバー の順 • 必要な作りこみ – をゲスト より先に落とさない – を落とす前に コマンドで分散ストレージを停止 • 対応 – 対応 ソリューションと連携 スクリプト作成を行う
- 18. 対応 連携シャットダウン製品の例 • ソリューションズ株式会社 – 自社製シャットダウンボックスと のセット提供 • オムロンソーシアル ソリューションズ株式会社 – 自社製 のネットワークカード に 対応シャットダウン制御機 能を組み込み 出典 出典
- 19. 設計
- 20. サイジング • ポイント – 基本は 台での構成 – いきなり 構成から入らない – ワークロード の要求リソース を洗い出す ▪ バックアップについても見積もる 世代数、保管期間等 ▪ を使うときは も必要 ▪ 的なものは特にない に組み込まれている • – 算出したワークロードを パートナーに伝えると、 の出力を基に適切な 構成が提示される – 特殊な 尖った 要件がある場合は必ず事前に伝えてください – 必ずしも万能ではないので、自動算出結果をベースに細かい調整をするケースも多い
- 22. ネットワーク設計 • のノードは各々が の スイッチに接続 –冗長構成必須 →「スイッチの故障でノード全断」は避ける – 前提 どちらでも – 用の ポート接続可能なスイッチも必ず用意 –スイッチの機種は性能と信頼性が担保できれば何でも →接続性に関する個別の はしません –パートナーさん毎に取り扱うスイッチが異なるので、 おススメを聞いてみてください
- 23. ネットワーク設計 • 物理ネットワークはいくつの系統に分けるのが推奨ですか？ – 多くの場合物理的は分けなくても大丈夫 ▪ 業務系 ゲスト 用 と管理系を分ける o通常は のみ、 が枯渇するほどであれば物理分割 oデータ分散処理やリモートレプリケーションは管理系を流れる o管理系が だと拡張時の手間が減る • その他の注意点は？ – のサブネットは管理 に使えない – ノード当たり アドレスが つ必要 クラスタに つ必要 – と は同セグメント必須、 は疎通可能な範囲
- 24. ネットワークアーキテクチャ • ベース – 設定変更に 関連の コマンドは使わない – 設定は コマンド ▪ から実行 – でゲスト を作ると自動で 全ノードに反映される ここが 出典
- 25. ネットワークダイヤグラム 出典
- 26. ストレージコンテナ • 仮想マシンを格納するデータストア –ストレージプール内に論理的に作成 –システムが自動作成するストレージコンテナは消さないこと –圧縮や重複排除の を使い分けたい場合に分ける –上限値の確認は ▪ • ストレージプール – 物理ディスクを束ねたグループ。 では基本的に全ディスクが つのストレージ プールに組み込まれるため「どのディスクでアレイを組んで 」等の考慮をする必要なし
- 27. 用リソースの予約 • の予約 はワンクリック – ノード分のリソースが予約され、 過剰な の起動が制限される – セグメント予約方式のみ ホスト予約方式は廃止
- 28. ゲスト の配置 • のアルゴリズムにお任せ – でいう に似たもの ▪ 起動の自動配置と、 稼働中のホットスポット回避 – だけでなくディスク も 配置の計算に含める ▪ データローカリティの有効性を保つ – デフォルトで ▪ どのホストにどの を置いて は不可能ではないが、 あまり合理的には思えない ※個人の意見です ▪ 特定の をホストに紐づけたければアフィニティ設定、全体をオフにするときは
- 29. アフィニティポリシー • アフィニティ – アプリケーションやミドルウェアの ホスト紐づきライセンスの順守等 – ルール • アンチアフィニティ – 冗長構成等の目的で複数立てた を 別のホストに分散させる – ルール – 設定は で実施 ▪
- 30. 構築
- 31. • のイメージングツール – にログインする直前まで自動セットアップ ▪ ハイパーバイザーのインストール ▪ のインストール ▪ クラスタの作成 • で必要項目を入れて、数十分待つだけ – パートナー各社による有償での実施代行も可
- 32. の種類 • 組込み型 – 出荷状態とは異なるハイパーバイザーや バージョンにしたいとき – 拡張時にも利用される 対象ノードがクラスタと異なる状態でイメージングされている場合 • 仮想アプライアンス型 – が稼働していないノードもイメージング可能 – 仮想アプライアンスを立てる必要あり • クライアントアプリケーション型 – 年 月時点
- 33. 前に確認・整理すべき項目 （※ のバージョンにより細かい差異あり） • ノード関連 – 通信用 スイッチの冗長化設定 なし – ノードポジション ベアメタルインストールの場合 • クラスタ関連 – • イメージファイル関連 –
- 34. その後の作業 • 初回アクセス – への同意と管理者パスワード設定 • ストレージコンテナを作る • イメージサービスに やゲスト の イメージをアップロード
- 35. 運用
- 36. ユーザーインターフェース • → いつもの • – 上で実行 ▪ 対話形式 ▪ ワンライナー • – を参照 ▪ 用 用
- 37. を使ってできる 関連のこと • の • の予約 – なので、起動優先度変更や個別 の除外は • パフォーマンス監視 • 健全性・アラート確認 • ハイパーバイザーのアップデート • バックアップ設定→詳細は さんパート
- 38. まとめ • 簡単です • 少人数での運用に対応しやすい • 学習コストの低さは大事です • 元研修会社のトレーナー視点 • 多くのユーザーに使っていただけているのは重要 • 自身が に開発リソースを投入できます • は試せます！ • のハイパーバイザーは • もあります 上での 時間お試し •