Nutanix Meetup Online 21.06の講演資料です。 イベントページはコチラ。 https://nutanix.connpass.com/event/214554/
ざっくり理解するの オペレーション
View Slide
はじめに– 本資料は、 年 月時点における弊社の一般的な製品情報を説明を主目的とするものです。– 本資料は情報提供を唯一の目的とするものであり、法律的またはその他の指導や助言を意図したものではなく、いかなる契約にも用いることはできません。– 本資料に含まれている情報については、完全性と正確性を期するよう努力しましたが、「現状」で提供され、明示的または暗示的に関わらず、いかなる保証も伴わないものとします。– 本資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害か生した場合も、及びニュータニックス・ジャパン合同会社は責任を負わないものとします。– 本資料で提供する情報やマテリアル、機能を確実に提供することを確約するものではありません。弊社製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。
オペレーションって？•いわゆる「運用」フェーズで行う諸々の作業– ：計画、設計、調達– ：構築、初期設定– ：運用▪監視、メンテナンス、トラブルシューティング等々、システムが正常稼働し続けるために必要なこと
今回のアジェンダにおけるオペレーションの概要システムの健全性を保つソフトウェアをサポート対象のバージョンに保つリソース枯渇を防ぐ
このセッションにはあまり含まない内容• バックアップ–重要な オペレーションではあるが、テーマ単体でのボリュームが大きいため• セキュリティ–重要な オペ• 自動化–重要な オペ
におけるオペレーションの概要
の主な運用管理ツール• 外部連携を伴う自動化の際には利用する可能性あり• プロダクト毎に が存在する• 一部のオペレーションでは最小限のコマンド操作が必要• 基本コマンドと 独自コマンドの組合せ• 定常運用タスクの殆どは で完結
ブラウザベースの統合管理ツール
と•– クラスター毎に存在– 内のサービスとして稼働•– 仮想アプライアンスで提供– 複数の クラスターを集中管理できる– 一部の 製品のためのプラットフォーム
は追加プロダクト用のプラットフォームでもある• 管理コンソールとして存在するのはと• は機械学習ベースの分析機能等のインテリジェントな運用管理機能を利用するための追加プロダクト、と捉えると分かりやすい
による一元管理ホストハードウェアの管理 ハイパーバイザーの管理ストレージの管理 仮想マシンの管理と操作
による一元管理バックアップ・ の管理 ネットワーク可視化ファイルサーバー の展開と管理 メトリックとアラートの相関分析
による一元管理インフラストラクチャーの健全性管理 ソフトウェアアップデートアラートの管理 ファームウェアアップデート
による高度な管理キャパシティ予測と管理非効率な の検出 セキュリティの管理定期レポートの自動生成
との比較①作業項目ソフトウェア、ファームウェア更新機器及びそれぞれの内部コンポーネントのアップデート情報を確認。ソフトウェア ファームウェア間での互換性を調査し、更新作業の順序を設計。で数クリック••監視機器ごとに異なる 、異なるフォーマットの情報を比較。横断的に監視を行うためには の監視システムが必要。• の健全性メニューを確認• を確認• メール通知の確認レポート作成機器ごとに異なるフォーマットのデータをそれぞれのから収集し、取りまとめる。• リソース情報や操作履歴の 出力• による自動レポート生成バックアップストレージ レベルでのバックアップや、バックアップツールによる レベルでのバックアップなど、環境及び要件に合わせたバックアップシステムを設計・構築。運用方法は選択した方式やツールにより異なる。• の保護ドメインメニュー• メイン 環境の運用性を共通化• 運用は で数クリック• バックアップ• により設計・構築を簡素化
との比較②作業項目スケールアウト（ノード増設）結線、 スイッチ、 スイッチの疎通、ストレージ装置の設定、ハイパーバイザーの設定などを更新した上で、ハイパーバイザーのクラスターに追加結線と スイッチの設定を行い、ノード間での疎通が可能な状態にするで数クリックスケールイン（ノード取外し）ホストをメンテナンスモードにし、ハイパーバイザーのクラスターから削除した上で、ハイパーバイザー、ストレージ装置、 スイッチの設定を更新 削除 し、取外しで数クリックスイッチの設定を更新 削除 し、取外し起動スイッチ、 スイッチ、ストレージ装置、サーバーの順で起動し、ハイパーバイザーがストレージを認識していることを確認スイッチを起動各ノードを起動ノード間の疎通が可能な状態でコマンドを実行停止ゲスト を停止ハイパーバイザーを停止ストレージ装置を停止スイッチの順で停止ゲスト を停止コマンドを実行をシャットダウンハイパーバイザーをシャットダウン
壊れないモノはありませんがはハードウェアもソフトウェアも絶対に壊れませんよ！！分散アーキテクチャで可用性を担保します• 部分的な障害の影響がシステム全体に及ばない様に単一障害点を排除したアーキテクチャ• 個々のコンポーネント単位の故障はある• ソフトウェア制御によるデータ冗長性回復機能により、他のシステムに比べて 障害時の交換を急ぐ必要性は薄い• 多くの場合において、 故障時の駆けつけ時間よりもサポートへのケースオープンやコミュニケーションをスムーズに行うことに注力したほうが吉
ここまでを踏まえてのポイント時間× 日、ずっと を見続けよう！しかもダブルチェックだ！！のコンセプトは『 』• 「存在を意識する必要がない」くらいシンプル• とはいえ「存在しない」わけではない以上意識しておくべきポイントはもちろんある勘所を押さえることで、過剰な運用負荷や過剰な人的コストを防ぐ、という方向が吉
システムの健全性を保つあるいは発生した問題を迅速に解決する
健全性確保に向けたフロー 超ざっくり問題発生を検知事象の詳細を把握＆解決策を検討解決策を適用潜在的リスクを発見影響範囲や解決策を調査
• 全体の健全性を数百項目に渡ってチェックする仕組み– 実体はスクリプト群– チェックの結果は、アラートの生成、健全性情報のテキストファイルでのレポート出力、 健全性 メニューの表示などに利用される– を週次で実行し、レポートをメールで受信することを推奨– 健全性を正しく管理するために、チェックの仕組みを健全に保つのが重要▪ 自身もソフトウェアなので、ワンクリックアップグレードでアップデートが可能
健全性 メニュー• のメニューの つ• で健全性をチェックし、状態を赤・黄・緑の段階で可視化– ホーム画面のウィジェットにも表示• 解決に役立ちそうなへのリンクを提示• オンデマンドでの 実行やログの収集もこのメニューから
• サポートポータルに診断情報を自動送信する機能– での送信がデフォルト も可能• 以下の情報が含まれる– システムアラート、 ソフトウェアバージョン、 関連コンポーネントのプロセス稼働状況や の情報、ハイパーバイザーの情報 種類やバージョン ※詳細情報– センシティブな情報は含まない、あるいはマスクされる▪ ゲスト 、ユーザーデータ、メタデータ、認証関連情報、 アドレスやホスト名などお客様環境✓ なしの場合 全 の通信を許可✓ ありの場合 の通信を許可取得した診断情報はサポートケースの自動起票や的確な対応の実現に役立てます
• 分析機能を備えたサポートポータル– 複数のサイトやクラスターに関する健全性やサポートケース一元的に表示– 健全性に関する予兆検知– 推奨される対応方法の提示– サポートケースの自動作成– サポートケース関連ログの自動採取• 要件– が有効化されていること
障害検知 サポート担当者による障害認知• システム側が検知するだけでなく、それをサポート担当に知らせる仕組みが必要– のダッシュボードや健全性メニューの目視– メール通知–– のノーコード自動化機能 によるアラートの外部通知▪▪▪
問題解決までの時間短縮を支援する仕組み名称 概要 主なタイミングサポートケースの起票にて手動で起票、アラートメール、 トラップなどにより異常を確認し、復旧にはサポートエンジニアの支援が必要と判断したときシステム情報を自動的にサポートに送信• 構成変更や障害：即時• メトリック： ～ 分毎• 構成情報： 時間毎お客様端末を介してサポートエンジニアが代理で操作問題解決に向けて対象システムの操作が必要な際サービスによるログや構成情報の自動収集の回線を利用ケース対応時にオンデマンドでユーザーの許可を得て サポートが取得
問題解決までの時間短縮を支援する仕組み名称 メリット 考慮事項サポートケースの起票 • サポート部門およびバックエンド 開発部門など による支援が受けられる• 人対人のやり取りのため、連絡頻度により、障害対応時間や作業負担が増加• システム情報取得および送付に要する手間と時間を削減• 外部通信の許可からのアウトバウンド• 作業負担や障害対応時間を削減• お客様に操作画面を見て頂きながらのリモート支援が可能• 外部通信の許可作業端末から へのアウトバウンドは不要• システム情報取得 特にログ および送付に要する手間と時間を削減• 外部通信の許可からのアウトバウンド
ログバンドル• やハイパーバイザーの構成情報・ログなどをひとまとめにした ファイル– トラブル対応時にサポートへの送付を求められる– ログコレクターにより生成▪ の健全性メニュー、またはコマンドで生成を実行▪ 指定したノード、指定したサービス、指定した期間のログを収集可能– のタスクダッシュボードからダウンロード、またはサポートへの直接アップロードが可能
ダークサイト運用ってどうなの？• ダークサイト＝すべての機器が一切インターネットに接続できない環境– 日本ではありがち カジュアルにこの構成を選びすぎでは– 海外でも無くはないが 政府機関、国防系などがメインであまり多くはない– サポート支援機能の利用が制限されるため、相対的に問題解決の難易度が上がったり、解決までの時間が長くなったりするなどのデメリットがある 目を逸らしてはいけない• 管理系ネットワーク構成の選択肢特定の通信元から特定の通信先への特定ポートでの通信を許可するインターネットへのアクセスを完全に遮断するどの機器も自由にインターネットに接続可能！
【必読！】サポートドキュメント日本語版• 実際に問題が起きたときに慌てないために、この資料で紹介していない項目も含め、ひととおり一度は目を通し、可能な範囲で予行練習をしてみることをお勧めします！–• ドキュメントの例– サポートポータルのユーザー登録– サポートケースのプライオリティの定義と対応時間– を使用したリモートサポート– アップグレードに関する– クラスターの健全性確認– ログの取得方法– アラートメールの設定– サポートへファイルを送付する– ホストとクラスターの停止・起動手順–特に重要度の高い項目以上を掲載中
ソフトウェアをサポート対象のバージョンに保つ
稼働中のシステムへの影響が怖い？ソフトウェアの塩漬けってどうなの？数年後に発動する時限爆弾的バグ新たな脆弱性新たな攻撃手法 更新による互換性の問題が事前調査で判明？アップデートの作業コストを抑えたい？• レガシーシステムのために全体をリスクに晒すことを許容できるか• あまりに多ければレガシー隔離用の基盤も検討• 重要度が低い場合は廃止も検討• 攻撃を受けたときの損害額や信頼失墜リスクのほうがはるかに大きい• なら数クリックでアップグレード可能• ならローリング 輪番 で更新✓ ゲスト は無停止✓ 最大 ノード分のリソース減をあらかじめ想定• 仮に更新処理が中断した場合もゲスト は動作継続✓ 更新処理の完了支援をサポートに依頼できるよう事前に準備更新すべき理由外的要因・制御不能塩漬けしたい理由社内事情・調整面倒
のサポートライフサイクル 最終更新• 緑 ：現行 メンテナンス対象• 黄 ： メンテナンス終了、サポート対象• 赤 ： サポート終了• ：現時点でまだ明記されていない部分製品ライフサイクル情報一覧およびアップデート関連の2020 2021 20221 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 55.10 LTS5.15 LTS5.16 STS5.17 STS5.18 STS5.19 STS5.20 LTS ? ? ? ? ? ? ? ? ? ? ? ?6.0 STS ? ? ? ? ? ?
• や 、 等のライフサイクルは、のライフサイクルとは異なりますのでご注意ください– 製品ごとのライフサイクル▪▪ と のバージョン互換性には注意すること▪ 実績として、 の互換は幅が広い傾向▪ は に紐づくが、 と直接的には紐づかない– との対応関係については も関わる▪– 基本的には → → →その他 利用 の順で更新するのがセオリー
の更新• ご利用中の環境では、 の更新前にの更新が必要となる場合があります というか基本的に を先に上げる– 上で警告表示あり– で互換性を確認可能
のライフサイクル 最終更新？ ？• に比べて短期間のライフサイクルとなっている点に注意
のライフサイクル 最終更新• とのバージョン互換性は厳しくないが、 自身のライフサイクルには注意
のワンクリックアップグレード 従来型更新対象コンポーネントを選択イメージファイル とメタデータ をアップロード ワンクリックダウンロード他のコンポーネントも更新する？アップグレードを実行
インベントリを実行定期実行も可能アップグレード対象コンポーネントとアップグレード先バージョンの選択アップグレードを実行バージョンと依存関係をチェック複数コンポーネント同時依存関係に応じた順序で自動実行
に関する備考• インターネットへのアウトバウンド通信が可能な場合– および の以下の通信を許可▪ 、ポート▪ 、ポート• ダークサイト インターネットへのアウトバウンド通信不可 の場合– 内部 サーバーを建てて以下のファイルをホストする必要あり▪ ファイル依存関係を定義した 大量の ファイルを固めた ファイル▪ ファイルが正しいものであることをチェック▪ 各プロダクトの 更新用データを固めた ファイル– で一部コンポーネントの直接アップロード対応を開始
ソフトウェア更新のポイント• 各バージョンのサポート期間の都合上、最低でも年に 回程度の アップグレードを想定– 約 年半 と 約半年 が存在する点に注意– 最新機能を追いかける場合を除いては は で– は年に 回程度の更新を見込む• アップグレード前に、システムの健全性をチェックし、問題がある場合はまずそれを解消してから• システム稼働中で問題ないが、高負荷なバッチの真っ最中や、明らかに業務負荷がピークを迎えている時間帯は避ける
特に重要度や影響度の高い情報の確認•–▪ 既知の重大な問題の詳細および回避方法–▪ 既知の脆弱性の詳細および対策方法– で更新情報の通知受け取り設定が可能▪ 画面右上▪ メールおよび の通知アイコン
リソース枯渇を防ぐ
基本となる考え方の場合またはの場合のリソースを予め確保するリソース割り当てを適正化 節約するそれでも足りなければスケールアウト
を確保する理由• ノードの停止や再起動を伴うメンテナンス時に仮想マシンを止めずに済むようにするため• ノードダウンが発生した場合に、 機能で仮想マシンを再稼働させるリソースを確保するため• ノードダウン発生中にもデータの冗長性 多重度 を確保するため• に関しては、オーバーコミットが可能なので余剰分の確保はメモリやディスクほど厳密に行わないケースもあるパフォーマンス低下を避けたい場合はしっかり確保
リソース割り当ての適正化• は の稼働状況を学習し、リソース割り当てが適正でないと考えられる をリストアップしてくれる• 休眠状態 日間の状態で判定– ずっと電源がオフ– 電源オンだが 合計 未満、かつ通信が 未満• 過剰な割り当て 下記項目を 日間、 条件で判定– 中程度– シビア 重度• リソース不足 下記項目を 日間、 条件で判定– 中程度– シビア 重度• 周囲に悪影響を及ぼす 下記の状態が 時間以上継続する場合–
追加ライセンスなしで出来る、カテゴリ管理を活用した緊急用リソースの確保 例• のカテゴリ機能– のセキュリティポリシー適用に使用することが多いが、 の単なる分類やフィルタリングにも使用可能– 分類項目を自由に作成可能– ではないので追加ライセンス不要• 分類の例：重要度による分類– カテゴリ名： 重要度▪ 常時起動しておきたい重要な▪ と の中間的な▪ 緊急時には勝手に止められてもいい、個人検証用などの
それでも足りなければスケールアウト導入時 年後 年後 年後 年後 年後 年後数層型仮想化基盤は拡張しづらい• 将来のリソース需要を予測し一括投資➢ 初期導入コストの大きさがプロジェクトを阻害➢ 設計・構築に長い時間を要する➢ 「過剰投資」 「過少予測によるリソース枯渇」の発生将来を予測して一括投資なら拡張しやすい• 最小 ノードでスタート• 投資のタイミングを分散• 過剰な安全マージンを抑制• 拡張時点の最新 を導入需要増に合わせて少しずつ投資例 投資と実際の利用 数
スモールスタート＆スケールアウトのポイント• クラウド的なインフラ投資・計画の考え方にシフトする– 必要な時に、必要な分だけ– ただし は 単位ではなく、ノード単位での投資となる– ノード調達のリードタイムを考慮すると、突然の枯渇には注意。のキャパシティ需要予測機能が役立つ。• 層型仮想化基盤とは、システム拡張時のストレージ性能に対する影響が「逆」であることを理解する– 層型 台の共有ストレージを利用するサーバーが増えるため性能リスクあり– 分散ストレージを提供するサーバーが増えるため性能が向上する• クラスター拡張前に、システムの健全性をチェックし、問題がある場合はまずそれを解消してから
まとめ
まとめ 色々お伝えしましたが要するにコレ✓ 問題をすぐに検知＆認知する準備を✓ トラブルが発生したときはサポートとのスムーズなコミュニケーションが最重要✓ ちゃんとアプデしよう✓ リソースは常に をキープ
smzksts
revcomm_inc
yuya4
etaroid
wakamatsu_takumu
aoshun7
tsukubachallenge
lemiorhan
oracle4engineer
orgachem
peisuke
wakamsha
i35_267
sferik
davidbonilla
sstephenson
rmw
mraible
thoeni
rasmusluckow
mthomps
speakerdeck
eileencodes
caitiem20
samlambert