ざっくり理解する Nutanix の Day 2 オペレーション

by Satoshi Shimazaki

Slide 1

Slide 1 text

ざっくり理解するのオペレーション

Slide 2

Slide 2 text

はじめに – 本資料は、年月時点における弊社の一般的な製品情報を説明を主目的とするものです。 – 本資料は情報提供を唯一の目的とするものであり、法律的またはその他の指導や助言を意図したものではなく、いかなる契約にも用いることはできません。 – 本資料に含まれている情報については、完全性と正確性を期するよう努力しましたが、「現状」で提供され、明示的または暗示的に関わらず、いかなる保証も伴わないものとします。 – 本資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害か生した場合も、及びニュータニックス・ジャパン合同会社は責任を負わないものとします。 – 本資料で提供する情報やマテリアル、機能を確実に提供することを確約するものではありません。弊社製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

Slide 3

Slide 3 text

オペレーションって？ •いわゆる「運用」フェーズで行う諸々の作業 – ：計画、設計、調達 – ：構築、初期設定 – ：運用 ▪監視、メンテナンス、トラブルシューティング等々、システムが正常稼働し続けるために必要なこと

Slide 4

Slide 4 text

今回のアジェンダにおけるオペレーションの概要システムの健全性を保つソフトウェアをサポート対象のバージョンに保つリソース枯渇を防ぐ

Slide 5

Slide 5 text

このセッションにはあまり含まない内容 • バックアップ –重要なオペレーションではあるが、テーマ単体でのボリュームが大きいため • セキュリティ –重要なオペ • 自動化 –重要なオペ

Slide 6

Slide 6 text

におけるオペレーションの概要

Slide 7

Slide 7 text

の主な運用管理ツール • 外部連携を伴う自動化の際には利用する可能性あり • プロダクト毎にが存在する • 一部のオペレーションでは最小限のコマンド操作が必要 • 基本コマンドと独自コマンドの組合せ • 定常運用タスクの殆どはで完結

Slide 8

Slide 8 text

ブラウザベースの統合管理ツール

Slide 9

Slide 9 text

と • – クラスター毎に存在 – 内のサービスとして稼働 • – 仮想アプライアンスで提供 – 複数のクラスターを集中管理できる – 一部の製品のためのプラットフォーム

Slide 10

Slide 10 text

は追加プロダクト用のプラットフォームでもある • 管理コンソールとして存在するのはと • は機械学習ベースの分析機能等のインテリジェントな運用管理機能を利用するための追加プロダクト、と捉えると分かりやすい

Slide 11

Slide 11 text

による一元管理ホストハードウェアの管理ハイパーバイザーの管理ストレージの管理仮想マシンの管理と操作

Slide 12

Slide 12 text

による一元管理バックアップ・の管理ネットワーク可視化ファイルサーバーの展開と管理メトリックとアラートの相関分析

Slide 13

Slide 13 text

による一元管理インフラストラクチャーの健全性管理ソフトウェアアップデートアラートの管理ファームウェアアップデート

Slide 14

Slide 14 text

による高度な管理キャパシティ予測と管理非効率なの検出セキュリティの管理定期レポートの自動生成

Slide 15

Slide 15 text

との比較① 作業項目ソフトウェア、ファームウェア更新機器及びそれぞれの内部コンポーネントのアップデート情報を確認。ソフトウェアファームウェア間での互換性を調査し、更新作業の順序を設計。で数クリック • • 監視機器ごとに異なる、異なるフォーマットの情報を比較。横断的に監視を行うためにはの監視システムが必要。 • の健全性メニューを確認 • を確認 • メール通知の確認レポート作成機器ごとに異なるフォーマットのデータをそれぞれのから収集し、取りまとめる。 • リソース情報や操作履歴の出力 • による自動レポート生成バックアップストレージレベルでのバックアップや、バックアップツールによるレベルでのバックアップなど、環境及び要件に合わせたバックアップシステムを設計・構築。運用方法は選択した方式やツールにより異なる。 • の保護ドメインメニュー • メイン環境の運用性を共通化 • 運用はで数クリック • バックアップ • により設計・構築を簡素化

Slide 16

Slide 16 text

との比較② 作業項目スケールアウト（ノード増設）結線、スイッチ、スイッチの疎通、ストレージ装置の設定、ハイパーバイザーの設定などを更新した上で、ハイパーバイザーのクラスターに追加結線とスイッチの設定を行い、ノード間での疎通が可能な状態にするで数クリックスケールイン（ノード取外し）ホストをメンテナンスモードにし、ハイパーバイザーのクラスターから削除した上で、ハイパーバイザー、ストレージ装置、スイッチの設定を更新削除し、取外しで数クリックスイッチの設定を更新削除し、取外し起動スイッチ、スイッチ、ストレージ装置、サーバーの順で起動し、ハイパーバイザーがストレージを認識していることを確認スイッチを起動各ノードを起動ノード間の疎通が可能な状態でコマンドを実行停止ゲストを停止ハイパーバイザーを停止ストレージ装置を停止スイッチの順で停止ゲストを停止コマンドを実行をシャットダウンハイパーバイザーをシャットダウン

Slide 17

Slide 17 text

壊れないモノはありませんがはハードウェアもソフトウェアも絶対に壊れませんよ！！分散アーキテクチャで可用性を担保します • 部分的な障害の影響がシステム全体に及ばない様に単一障害点を排除したアーキテクチャ • 個々のコンポーネント単位の故障はある • ソフトウェア制御によるデータ冗長性回復機能により、他のシステムに比べて障害時の交換を急ぐ必要性は薄い • 多くの場合において、故障時の駆けつけ時間よりもサポートへのケースオープンやコミュニケーションをスムーズに行うことに注力したほうが吉

Slide 18

Slide 18 text

ここまでを踏まえてのポイント時間× 日、ずっとを見続けよう！しかもダブルチェックだ！！のコンセプトは『』 • 「存在を意識する必要がない」くらいシンプル • とはいえ「存在しない」わけではない以上意識しておくべきポイントはもちろんある勘所を押さえることで、過剰な運用負荷や過剰な人的コストを防ぐ、という方向が吉

Slide 19

Slide 19 text

システムの健全性を保つあるいは発生した問題を迅速に解決する

Slide 20

Slide 20 text

健全性確保に向けたフロー超ざっくり問題発生を検知事象の詳細を把握＆解決策を検討解決策を適用潜在的リスクを発見影響範囲や解決策を調査

Slide 21

Slide 21 text

• 全体の健全性を数百項目に渡ってチェックする仕組み – 実体はスクリプト群 – チェックの結果は、アラートの生成、健全性情報のテキストファイルでのレポート出力、健全性メニューの表示などに利用される – を週次で実行し、レポートをメールで受信することを推奨 – 健全性を正しく管理するために、チェックの仕組みを健全に保つのが重要 ▪ 自身もソフトウェアなので、ワンクリックアップグレードでアップデートが可能

Slide 22

Slide 22 text

健全性メニュー • のメニューのつ • で健全性をチェックし、状態を赤・黄・緑の段階で可視化 – ホーム画面のウィジェットにも表示 • 解決に役立ちそうなへのリンクを提示 • オンデマンドでの実行やログの収集もこのメニューから

Slide 23

Slide 23 text

• サポートポータルに診断情報を自動送信する機能 – での送信がデフォルトも可能 • 以下の情報が含まれる – システムアラート、ソフトウェアバージョン、関連コンポーネントのプロセス稼働状況やの情報、ハイパーバイザーの情報種類やバージョン ※詳細情報 – センシティブな情報は含まない、あるいはマスクされる ▪ ゲスト、ユーザーデータ、メタデータ、認証関連情報、アドレスやホスト名などお客様環境 ✓ なしの場合全の通信を許可 ✓ ありの場合の通信を許可取得した診断情報はサポートケースの自動起票や的確な対応の実現に役立てます

Slide 24

Slide 24 text

• 分析機能を備えたサポートポータル – 複数のサイトやクラスターに関する健全性やサポートケース一元的に表示 – 健全性に関する予兆検知 – 推奨される対応方法の提示 – サポートケースの自動作成 – サポートケース関連ログの自動採取 • 要件 – が有効化されていること

Slide 25

Slide 25 text

障害検知サポート担当者による障害認知 • システム側が検知するだけでなく、それをサポート担当に知らせる仕組みが必要 – のダッシュボードや健全性メニューの目視 – メール通知 – – のノーコード自動化機能によるアラートの外部通知 ▪ ▪ ▪

Slide 26

Slide 26 text

問題解決までの時間短縮を支援する仕組み名称概要主なタイミングサポートケースの起票にて手動で起票、アラートメール、トラップなどにより異常を確認し、復旧にはサポートエンジニアの支援が必要と判断したときシステム情報を自動的にサポートに送信 • 構成変更や障害：即時 • メトリック：～分毎 • 構成情報：時間毎お客様端末を介してサポートエンジニアが代理で操作問題解決に向けて対象システムの操作が必要な際サービスによるログや構成情報の自動収集の回線を利用ケース対応時にオンデマンドでユーザーの許可を得てサポートが取得

Slide 27

Slide 27 text

問題解決までの時間短縮を支援する仕組み名称メリット考慮事項サポートケースの起票 • サポート部門およびバックエンド開発部門などによる支援が受けられる • 人対人のやり取りのため、連絡頻度により、障害対応時間や作業負担が増加 • システム情報取得および送付に要する手間と時間を削減 • 外部通信の許可からのアウトバウンド • 作業負担や障害対応時間を削減 • お客様に操作画面を見て頂きながらのリモート支援が可能 • 外部通信の許可作業端末からへのアウトバウンドは不要 • システム情報取得特にログおよび送付に要する手間と時間を削減 • 外部通信の許可からのアウトバウンド

Slide 28

Slide 28 text

ログバンドル • やハイパーバイザーの構成情報・ログなどをひとまとめにしたファイル – トラブル対応時にサポートへの送付を求められる – ログコレクターにより生成 ▪ の健全性メニュー、またはコマンドで生成を実行 ▪ 指定したノード、指定したサービス、指定した期間のログを収集可能 – のタスクダッシュボードからダウンロード、またはサポートへの直接アップロードが可能

Slide 29

Slide 29 text

ダークサイト運用ってどうなの？ • ダークサイト＝すべての機器が一切インターネットに接続できない環境 – 日本ではありがちカジュアルにこの構成を選びすぎでは – 海外でも無くはないが政府機関、国防系などがメインであまり多くはない – サポート支援機能の利用が制限されるため、相対的に問題解決の難易度が上がったり、解決までの時間が長くなったりするなどのデメリットがある目を逸らしてはいけない • 管理系ネットワーク構成の選択肢特定の通信元から特定の通信先への特定ポートでの通信を許可するインターネットへのアクセスを完全に遮断するどの機器も自由にインターネットに接続可能！

Slide 30

Slide 30 text

【必読！】サポートドキュメント日本語版 • 実際に問題が起きたときに慌てないために、この資料で紹介していない項目も含め、ひととおり一度は目を通し、可能な範囲で予行練習をしてみることをお勧めします！ – • ドキュメントの例 – サポートポータルのユーザー登録 – サポートケースのプライオリティの定義と対応時間 – を使用したリモートサポート – アップグレードに関する – クラスターの健全性確認 – ログの取得方法 – アラートメールの設定 – サポートへファイルを送付する – ホストとクラスターの停止・起動手順 – 特に重要度の高い項目以上を掲載中

Slide 31

Slide 31 text

ソフトウェアをサポート対象のバージョンに保つ

Slide 32

Slide 32 text

稼働中のシステムへの影響が怖い？ソフトウェアの塩漬けってどうなの？数年後に発動する時限爆弾的バグ新たな脆弱性新たな攻撃手法更新による互換性の問題が事前調査で判明？アップデートの作業コストを抑えたい？ • レガシーシステムのために全体をリスクに晒すことを許容できるか • あまりに多ければレガシー隔離用の基盤も検討 • 重要度が低い場合は廃止も検討 • 攻撃を受けたときの損害額や信頼失墜リスクのほうがはるかに大きい • なら数クリックでアップグレード可能 • ならローリング輪番で更新 ✓ ゲストは無停止 ✓ 最大ノード分のリソース減をあらかじめ想定 • 仮に更新処理が中断した場合もゲストは動作継続 ✓ 更新処理の完了支援をサポートに依頼できるよう事前に準備更新すべき理由外的要因・制御不能塩漬けしたい理由社内事情・調整面倒

Slide 33

Slide 33 text

のサポートライフサイクル最終更新 • 緑：現行メンテナンス対象 • 黄：メンテナンス終了、サポート対象 • 赤：サポート終了 • ：現時点でまだ明記されていない部分製品ライフサイクル情報一覧およびアップデート関連の 2020 2021 2022 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 5.10 LTS 5.15 LTS 5.16 STS 5.17 STS 5.18 STS 5.19 STS 5.20 LTS ? ? ? ? ? ? ? ? ? ? ? ? 6.0 STS ? ? ? ? ? ?

Slide 34

Slide 34 text

• や、等のライフサイクルは、のライフサイクルとは異なりますのでご注意ください – 製品ごとのライフサイクル ▪ ▪ とのバージョン互換性には注意すること ▪ 実績として、の互換は幅が広い傾向 ▪ はに紐づくが、と直接的には紐づかない – との対応関係についてはも関わる ▪ – 基本的には → → →その他利用の順で更新するのがセオリー

Slide 35

Slide 35 text

の更新 • ご利用中の環境では、の更新前にの更新が必要となる場合がありますというか基本的にを先に上げる – 上で警告表示あり – で互換性を確認可能

Slide 36

Slide 36 text

のライフサイクル最終更新？？ • に比べて短期間のライフサイクルとなっている点に注意

Slide 37

Slide 37 text

のライフサイクル最終更新 • とのバージョン互換性は厳しくないが、自身のライフサイクルには注意

Slide 38

Slide 38 text

のワンクリックアップグレード従来型更新対象コンポーネントを選択イメージファイルとメタデータをアップロードワンクリックダウンロード他のコンポーネントも更新する？アップグレードを実行

Slide 39

Slide 39 text

インベントリを実行定期実行も可能アップグレード対象コンポーネントとアップグレード先バージョンの選択アップグレードを実行バージョンと依存関係をチェック複数コンポーネント同時依存関係に応じた順序で自動実行

Slide 40

Slide 40 text

に関する備考 • インターネットへのアウトバウンド通信が可能な場合 – およびの以下の通信を許可 ▪ 、ポート ▪ 、ポート • ダークサイトインターネットへのアウトバウンド通信不可の場合 – 内部サーバーを建てて以下のファイルをホストする必要あり ▪ ファイル依存関係を定義した大量のファイルを固めたファイル ▪ ファイルが正しいものであることをチェック ▪ 各プロダクトの更新用データを固めたファイル – で一部コンポーネントの直接アップロード対応を開始

Slide 41

Slide 41 text

ソフトウェア更新のポイント • 各バージョンのサポート期間の都合上、最低でも年に回程度のアップグレードを想定 – 約年半と約半年が存在する点に注意 – 最新機能を追いかける場合を除いてははで – は年に回程度の更新を見込む • アップグレード前に、システムの健全性をチェックし、問題がある場合はまずそれを解消してから • システム稼働中で問題ないが、高負荷なバッチの真っ最中や、明らかに業務負荷がピークを迎えている時間帯は避ける

Slide 42

Slide 42 text

特に重要度や影響度の高い情報の確認 • – ▪ 既知の重大な問題の詳細および回避方法 – ▪ 既知の脆弱性の詳細および対策方法 – で更新情報の通知受け取り設定が可能 ▪ 画面右上 ▪ メールおよびの通知アイコン

Slide 43

Slide 43 text

リソース枯渇を防ぐ

Slide 44

Slide 44 text

基本となる考え方の場合またはの場合のリソースを予め確保するリソース割り当てを適正化節約するそれでも足りなければスケールアウト

Slide 45

Slide 45 text

を確保する理由 • ノードの停止や再起動を伴うメンテナンス時に仮想マシンを止めずに済むようにするため • ノードダウンが発生した場合に、機能で仮想マシンを再稼働させるリソースを確保するため • ノードダウン発生中にもデータの冗長性多重度を確保するため • に関しては、オーバーコミットが可能なので余剰分の確保はメモリやディスクほど厳密に行わないケースもあるパフォーマンス低下を避けたい場合はしっかり確保

Slide 46

Slide 46 text

リソース割り当ての適正化 • はの稼働状況を学習し、リソース割り当てが適正でないと考えられるをリストアップしてくれる • 休眠状態日間の状態で判定 – ずっと電源がオフ – 電源オンだが合計未満、かつ通信が未満 • 過剰な割り当て下記項目を日間、条件で判定 – 中程度 – シビア重度 • リソース不足下記項目を日間、条件で判定 – 中程度 – シビア重度 • 周囲に悪影響を及ぼす下記の状態が時間以上継続する場合 –

Slide 47

Slide 47 text

追加ライセンスなしで出来る、カテゴリ管理を活用した緊急用リソースの確保例 • のカテゴリ機能 – のセキュリティポリシー適用に使用することが多いが、の単なる分類やフィルタリングにも使用可能 – 分類項目を自由に作成可能 – ではないので追加ライセンス不要 • 分類の例：重要度による分類 – カテゴリ名：重要度 ▪ 常時起動しておきたい重要な ▪ との中間的な ▪ 緊急時には勝手に止められてもいい、個人検証用などの

Slide 48

Slide 48 text

それでも足りなければスケールアウト導入時年後年後年後年後年後年後数層型仮想化基盤は拡張しづらい • 将来のリソース需要を予測し一括投資 ➢ 初期導入コストの大きさがプロジェクトを阻害 ➢ 設計・構築に長い時間を要する ➢ 「過剰投資」「過少予測によるリソース枯渇」の発生将来を予測して一括投資なら拡張しやすい • 最小ノードでスタート • 投資のタイミングを分散 • 過剰な安全マージンを抑制 • 拡張時点の最新を導入需要増に合わせて少しずつ投資例投資と実際の利用数

Slide 49

Slide 49 text

スモールスタート＆スケールアウトのポイント • クラウド的なインフラ投資・計画の考え方にシフトする – 必要な時に、必要な分だけ – ただしは単位ではなく、ノード単位での投資となる – ノード調達のリードタイムを考慮すると、突然の枯渇には注意。のキャパシティ需要予測機能が役立つ。 • 層型仮想化基盤とは、システム拡張時のストレージ性能に対する影響が「逆」であることを理解する – 層型台の共有ストレージを利用するサーバーが増えるため性能リスクあり – 分散ストレージを提供するサーバーが増えるため性能が向上する • クラスター拡張前に、システムの健全性をチェックし、問題がある場合はまずそれを解消してから

Slide 50

Slide 50 text

まとめ

Slide 51

Slide 51 text

まとめ色々お伝えしましたが要するにコレ ✓ 問題をすぐに検知＆認知する準備を ✓ トラブルが発生したときはサポートとのスムーズなコミュニケーションが最重要 ✓ ちゃんとアプデしよう ✓ リソースは常にをキープ