移植性に注目
Windows Server 2016のコンテナ機能が災害復旧に有効な理由
Windowsコンテナは簡単に移植できることから、確実な災害復旧の機会を提供する。だが、まずはこれをいつ、どう利用すべきかの詳細について理解しておく必要がある。
Windowsコンテナの概要（出典：Microsoft）《クリックで拡大》
「Windows Server 2016」で新たに搭載されたコンテナ機能が大きな注目を集めている。このコンテナは「Docker」をベースとしていてアプリケーション仮想化に利用でき、アプリケーションの移植を可能にするという付加価値もある。WindowsコンテナはデスクトップPCで作成し、データセンターのサーバで運用して、コードに特段手を加えることなくクラウドに移植できる。コンテナは移植性が高く、アプリケーションをパブリッククラウドや代替データセンターに簡単に移せることから災害復旧（DR）のための選択肢としても興味深い。
Windowsコンテナのコンポーネントと移植問題
コンテナは移植可能ではあるが、手当たり次第にコンテナを1つの環境から別の環境へと移植すればコンテナ化されたアプリケーションに問題を生じさせることもある。そうした問題は、コンテナの仕組みに直接的に起因する。
Windows Server 2016では、「Windows Serverコンテナ」と「Hyper-Vコンテナ」という異なる2種類のコンテナを作成できる。いずれの場合も、Windowsコンテナはコンテナホストによって実行される。ホストはコンテナが置かれる物理マシンまたは仮想マシンを指す。
コンテナホストは仮想ホストと同じようなものと考えがちだが、実は大きな違いがある。仮想マシン（VM）は完全な自己完結型で、自前のOSやハードウェア設定などを持つ。これに対してコンテナには自前のOSは内蔵されていない。
コンテナOSイメージはそれぞれのコンテナのOSとして機能し、一般的に、複数のコンテナが共通のコンテナOSイメージを共有する。このアプローチの利点として、一連のVMをホスティングしている仮想ホストのように、複数のサーバOSを実行することによってホストリソースを浪費せずに済む。コンテナOSイメージは複数のコンテナによって共有できるため、OSイメージは読み込みのみに対応する。
コンテナは主に、コンテナイメージとサンドボックスの2つのコンポーネントで構成される。イメージは一般的に、仮想化されたアプリケーションを保存する。例えば1つのコンテナにはアプリケーションのバイナリとレジストリキーなどが保存されている。イメージは読み込みしかできない。レジストリの更新など書き込み操作はコンテナのサンドボックスに対して行われる。
コンテナは移植を想定した設計になっているが、移植性に影響を及ぼす要素が幾つかある。その1つがコンテナOSイメージの依存関係だ。例えばWindows Server 2016をOSイメージのベースとするWindows Serverコンテナを作成したとする。災害が起きてそのWindowsコンテナを、クラウドベースコンテナホストでホスティングされたパブリッククラウドに移したとしても、恐らくLinuxホスト上でそのコンテナを機能させることはできない。WindowsとLinuxは両方ともDockerコンテナをサポートしているが、その根底にあるカーネルの違いはあまりに大きい。
クラウドベースのWindows Serverコンテナホストでコンテナを正しく実行するためには、そのコンテナのOSイメージのコピーなど、依存関係にあるイメージを必要とする。
幸いなことに、コンテナOSイメージは標準化が進む傾向にある。Windows Server 2016環境ではコンテナイメージパッケージプロバイダーをインストールし、それを使ってコンテナOSイメージを生成できる。Windows Server CoreベースのOSイメージを作成したい場合は、Dockerのインストールと設定が済んでいることを前提として、以下の3行のコマンドを入力する。
Install-PackageProvider ContainerImage -Force
Install-ContainerImage -Name WindowsServerCore
Restart-Service Docker
データを移行する際の注意点
コンテナの移植性に関する最大級の課題としてコンテナデータボリュームの移行が挙げられる。コンテナデータボリュームではコンテナデータディレクトリの作成や、既存のデータディレクトリの追加ができる。データボリュームを複数のコンテナ間で共有することも可能だ。
大切なのは、データボリュームはコンテナの外に存在するという認識だ。たとえそれを使っているコンテナを削除したとしても、データボリュームは残る。
コンテナが実行中または一時停止中であれば、移行するには一般的にDockerエクスポートコマンドを使う。もし実行していないコンテナであれば、Docker保存コマンドを利用する。両コマンドともコンテナをファイルに保存して、別のホストへ移植できる状態にする。問題は、データボリュームがコンテナの外にあることから、エクスポートされたファイルに含まれないという点だ。
現時点でデータボリュームを扱う最善の方法は、バックアップしておいて、コンテナを移行した後に復旧することだ。
Windowsコンテナは、コンテナ化されたアプリケーションをクラウドや代替ホストに移植できることから、災害復旧のための優れたツールになり得る。だが、依存関係が崩れることを防ぐため、あるいはデータボリュームを失うことを防ぐためには慎重さが求められる。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
事例
[サイボウズ株式会社] DXに必要な「Dスキル」「Xスキル」を持った人材を育成するには？ -
市場調査・トレンド
[サイボウズ株式会社] データで見る、DXが「順調に進む企業」と「つまずく企業」の違い -
製品資料
[サイボウズ株式会社] 賛否が割れがちな「Notesからの移行」 新環境への移行を納得してもらうには？ -
事例
[ServiceNow Japan合同会社] 農林中金に学ぶ内製開発 処理効率を約2倍に高めAI活用も加速させた方法とは？ -
事例
[ServiceNow Japan合同会社] NTTグループのデジタル変革術、17万人が利用する決裁プロセス刷新の全貌
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「VMware離れ」は本当か 3000社がVCF 9にかじを切った現実的な理由
-
2
MS月例パッチが1000件突破 人手不足の情シスを襲う「月1回メンテ」の崩壊
-
3
「Microsoft一択」で本当にいいのか 知らぬ間にライセンス費用が膨らむ真相
-
4
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
5
「Microsoft 365」が乗っ取られる 跡形もなくMFAを破る手口
-
6
Oracle巨大ITプロジェクトはなぜつまずいたのか 8年で導入1割、追加で170億ドル
-
7
【基本情報技術者試験】「デュプレックスシステム」と「デュアルシステム」の違いは？
-
8
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
9
AIが勝手に本番DBを削除 7割が悩むコード生成の実態と現場の防衛策
-
10
「ITインフラとデータ保護・バックアップ対策」に関するアンケート
ホワイトペーパーランキング PR
-
1
生成AIのハルシネーションを防止 回答精度を高めるセマンティックレイヤーとは
-
2
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
3
5回聞くだけじゃ足りない？ トヨタ式「なぜなぜ分析」の正しい実践方法
-
4
AIが「わざわざ使うツール」になっていない？ 業務で自然に使う導線にする秘訣
-
5
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは？
-
6
「脱Excel」か「Excel快適化」か？ 現場にやさしい業務改善の進め方
-
7
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
8
マンガで解説：「ゼロトラスト」「SASE」の必要性とメリット
-
9
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
10
情報セキュリティ対策早分かりガイド：25の自社診断で弱点と解決策を理解
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー