ネスペ勉強メモ5【設計】
ネスペ試験の個人メモです
仮想化設計
ハイパーバイザ型(VMware)とコンテナ化(Docker)の比較
環境の独立性
ハイパーバイザは完全に独立しているのに対して、コンテナは完全ではない(OS、カーネル、ドライバが共通)
リソースの消費量
ハイパーバイザ型は膨大だが、コンテナ化は少ない
起動時間
ハイパーバイザ型は数分かかる、コンテナは数秒で起動する
イメージのサイズ
ハイパーバイザ型は膨大、コンテナは小さい
コンテナの用語
ボリューム … 共通ディレクトリ領域のこと
ポートフォワーディング … コンテナ内のポート番号をホストマシンの外側のポート番号に変換する機能
マイクロサービスアーキテクチャ … コンテナ作成時基本的に1アプリケーション1コンテナにするシステム形態のこと
オーケストレーション … コンテナ全体を容易に管理すること(k8sのこと)
ローリングアップデート … 複数のコンテナをクラウド環境にアップデートする場合、何回かに分けてデプロイすること。オーケストレーションがなされていれば容易できる。
仮想マシンの設計
冗長化の方式
冗長化の方式には以下の2つの方式がある。
アクティブ/スタンバイ方式
プライマリサーバで障害が発生したら、セカンダリサーバで仮想マシンを再起動する方式。ハートビートパケットを交換することで障害の検知を確認できる。2台の物理サーバ間でストレージを共有し、ストレージに仮想マシンのイメージファイルを格納しておく。切り替え時間は数分かかる。
デュアル方式
2台の物理サーバ上で同じ仮想マシンを動かしておく。ハートビートパケットを交換することで障害の検知を確認できる。2台の物理サーバ間を専用ネットワークで繋いで、動作情報の同期を常にとりつづける。切り替え時間は常に点いてるため一瞬で切り替わる。
仮想マシンの移動
フェールオーバ(障害発生時に自動でシステムを切り替えること)やライブマイグレーション(仮想マシンをOSやアプリケーションを停止させることなく、丸ごと別の物理サーバへと移動させること)により、仮想マシンが別の物理サーバに移動して稼働する時RARPフレームを送信して、同一サブネットに存在するL2スイッチのMACアドレステーブルを更新する。
サーバ自体が切り替わって何事もなかったとしてもそれに付随するスイッチはそのまま使っているため、そのままだとMACアドレステーブル(MACアドレスとポートの対応表)がズレているため通信に支障がでる。
従って、物理サーバ移動後にRARPフレームを投げる。するとL2スイッチは今まで通信していたポートとは別のポートから通信をうけるため、MACアドレステーブルを更新する。
ライブマイグレーション
下記のような構成を考える。
物理サーバ1 {仮想マシン1}
物理サーバ2 {仮想マシン2, 3, 4}
このとき仮想マシン2の負荷が高くなると
物理サーバ1 {仮想マシン1, 2}
物理サーバ1 {仮想マシン3, 4}
のように物理サーバ間で自動で移動ししてくれる。このときのダウンタイムはほぼゼロである。
故に、余裕を持ったキャパシティ設定をする必要がある。たとえば以下を考える。
物理サーバ1 {仮想1, 2}
物理サーバ2 {仮想3, 4}
物理サーバ3 {仮想5, 6}
この時物理サーバ3が死ぬと
物理サーバ1 {仮想1, 2, 5}
物理サーバ2 {仮想3, 4, 6}
とライブマイグレーションを実行できるが、物理サーバ自体のキャパシティが少ないと仮想1,2,3,4にも影響を与えかねないので注意が必要。
シンクライアント導入に伴うPCの仮想化
シンクライアント(TC) … (Thin: 薄い、細いの意味)。端末自体にはデータやアプリケーションなどを保存せず、社内にあるサーバーでほとんどすべての情報を管理するシステムのこと
シンクライアントを導入することで運用管理の省力化やセキュリティ強化を図ることができる。
この記事が気に入ったらサポートをしてみませんか?