Veritas InfoScale™ 8.0.2 仮想化ガイド - Linux
- 第 I 部 Linux 仮想化で使う Veritas InfoScale Solutions の概要
- 第 II 部 基本 KVM 環境の実装
- 基本 KVM のスタートガイド
- KVM (カーネルベースの仮想マシン)ホストの作成および起動
- RHEL ベースの KVM のインストールと使用法
- KVM (カーネルベースの仮想マシン) ゲストの設定
- Veritas InfoScale Solutions での KVM の設定について
- カーネルベースの仮想マシン環境の Veritas InfoScale Solutions 設定オプション
- KVM ゲスト仮想化マシンの Dynamic Multi-Pathing
- KVM ホストでの Dynamic Multi-Pathing
- 仮想化ゲストマシンでの Storage Foundation
- KVM ゲストでの I/O フェンシングの有効化
- KVM ホストでの Storage Foundation Cluster File System High Availability
- KVM ホストとゲスト仮想マシンの Dynamic Multi-Pathing
- KVM ホストの Dynamic Multi-Pathing と KVM ゲスト仮想マシンの Storage Foundation HA
- KVM ホストでの Cluster Server
- ゲストでの Cluster Server
- 複数の仮想マシンゲストと物理コンピュータにわたるクラスタ内の Cluster Server
- カーネルベースの仮想マシン環境での Veritas InfoScale Solutions のインストール
- KVM(カーネルベースの仮想マシン)環境の Cluster Server のインストールと設定
- KVM リソースの設定
- 基本 KVM のスタートガイド
- 第 III 部 Linux 仮想化実装の使用例
- アプリケーションの可視性とデバイス検出
- Veritas InfoScale Operations Manager を使ったストレージからアプリケーションへの可視性の使用について
- Veritas InfoScale Operations Manager でのカーネルベースの仮想マシン(KVM)の仮想化検出
- Veritas InfoScale Operations Manager の Red Hat Enterprise Virtualization(RHEV)仮想化の検出について
- Microsoft Hyper-V 仮想化の検出について
- Microsoft Hyper-V での仮想マシンの検出
- Microsoft Hyper-V でのストレージマッピングの検出
- サーバー統合
- 物理から仮想への移行
- 簡素化した管理
- Cluster Server を使用するアプリケーションの可用性
- 仮想マシンの可用性
- ライブ移行を使った仮想マシンの可用性
- Red Hat Enterprise Virtualization 環境での仮想から仮想へのクラスタ化
- Microsoft Hyper-V 環境での仮想から仮想へのクラスタ化
- OVM (Oracle Virtual Machine) 環境での仮想から仮想へのクラスタ化
- Red Hat Enterprise 仮想化環境での仮想化マシンに対するディザスタリカバリ
- Red Hat Enterprise Virtualization 仮想マシンに対するディザスタリカバリについて
- RHEV 環境での DR の要件
- Volume Replicator(VVR)と Veritas File Replicator(VFR)を使用するボリュームとファイルシステムの障害回復
- Storage Foundation コンポーネントをバックエンドストレージとして設定する
- DR サイト間のレプリケーションのために VCS GCO オプションで VVR および VFR を設定します
- Cluster Server(VCS)を使った RHEV(Red Hat Enterprise Virtualization)仮想マシンでのディザスタリカバリの設定
- 多層型ビジネスサービスのサポート
- InfoScale Enterprise を使用した Docker コンテナの管理
- InfoScale Enterprise 製品による Docker コンテナの管理について
- Docker、Docker Daemon、および Docker Container 用の Cluster Server エージェントについて
- Docker コンテナのストレージ容量の管理
- Docker コンテナのオフライン移行
- Docker 環境におけるボリュームとファイルシステムのディザスタリカバリ
- Docker コンテナの管理時の制限事項
- アプリケーションの可視性とデバイス検出
- 第 IV 部 参照先
- 付録 A. トラブルシューティング
- 仮想マシンのライブ移行のトラブルシューティング
- Red Hat Enterprise Virtualization(RHEV)環境でのライブ移行のストレージ接続
- Red Hat Enterprise Virtualization(RHEV)仮想マシンのディザスタリカバリ(DR)のトラブルシューティング
- KVMGuest リソースが、ホストへのストレージ接続が失われてもオンライン状態のままになる
- 仮想マシンが実行されているホストのネットワーク接続が失われると、VCS が仮想マシンのフェールオーバーを開始する
- RHEV 環境で、間違ったブート順序により仮想マシンの起動に失敗する
- RHEV 環境で、仮想マシンが wait_for_launch 状態でハングアップして起動に失敗する
- DROpts 属性が設定されていない場合、VCS が別の RHEV クラスタのホストの仮想マシンの起動に失敗する
- 仮想マシンが RHEV 環境で接続されているネットワークカードの検出に失敗する
- hares -modify コマンドの -add オプションまたは -delete オプションを使って RHEVMInfo 属性のいずれかのキーを更新すると、KVMGuest エージェントの動作が未定義になる
- RHEV 環境: VM が動作しているノードがパニックに陥るか強制的にシャットダウンされる場合、VCS は別のノードで VM を開始できない
- 付録 B. 設定例
- 付録 C. 他の情報参照場所
- 付録 A. トラブルシューティング
領域最適化スナップショットによるストレージの節約
物理サーバーごとに格納される仮想マシンが多数ある場合、単一サーバーで使われるブートイメージの数も多くなります。 単一のベアメタル Linux のブートイメージは少なくとも約 3 GB の領域を必要とします。 それに加えてソフトウェアスタックとアプリケーションバイナリをインストールすると領域がさらに必要となり、通常はデータベースアプリケーションを格納する各仮想マシンに約 6 GB の領域を使うことになります。
ユーザーが新しい仮想マシンをプロビジョニングする際に、ブートイメージは完全コピーまたは領域最適化スナップショットの場合があります。 完全コピーを使うと、ストレージの使用が非常に非効率的になります。 同一のブートイメージを格納するためにストレージが消費されるだけでなく、ブートイメージを高可用性にするため(複数のエンクロージャにわたるミラー)とバックアップにおいてもストレージが消費されます。この高可用性で高パフォーマンスの大量ストレージは非常に高価であるため、サーバー仮想化によって通常は実現されるコストの利点を生かすことができません。 それに加えて、大容量のバックアップとリカバリも高価なタスクになります。
上記の問題に対処するためには、さまざまな VM ゲストのブートイメージとしてゴールドイメージの領域最適化スナップショットを使用することを推奨します。 領域最適化スナップショットは、ゴールドイメージのデータの完全コピーを作成するのではなく、変更されたブロックのみをローカルに格納するコピーオンライト原則(物理ストレージによってバッキングされる)に基づいて機能します。この変更されたブロックのセットはキャッシュオブジェクトと呼ばれ、すべての領域最適化スナップショットのリポジトリ(キャッシュオブジェクトストアと呼ばれる)に格納されます。 キャッシュオブジェクトはストレージ領域を大幅に削減するため、親ボリューム(この場合はゴールドイメージボリューム)と比較して通常は 5 ~ 20% のストレージ占有領域を占めます。 同じキャッシュオブジェクトストアは、複数のスナップショットボリュームの変更されたブロックを格納するために使うことができます。
インストールのブート環境をサポートするために、キャッシュオブジェクトストアで保持される各スナップショットにはゴールドイメージに対して行われた変更のみが含まれます。 したがって、ストレージを最大限に削減するには、ルートファイルシステムではなくデータディスクでソフトウェアをインストールしてください。また、ゴールドイメージ操作ファイル(つまり、システム、ホスト、パスワードなど)に対する変更を制御することにも努めてください。