（2016年時点での内容をアーカイブとして掲載しているため、一部の掲載内容が最新情報とは異なる場合がありますので、ご了承ください。最新のIBM Cloudの情報は IBM Cloud Docs や IBM Cloud アップデート情報 、柔らか層本をご参照ください。）
解決したい課題
可用性向上や負荷対策など、クラスターメンバーとして設定済みサーバーを増設するケース、また、ロードバランサー配下に同一設定のウェブ・サーバーを追加するケースなどがある。このようなケースに対して、サーバーを個々に設定していたのでは、時間と技術者が多く必要になり、ビジネス・チャンスを逃してしまう課題がある。
ソリューション・パターン
最初に設定するサーバーをマスターとしてイメージ・テンプレートを作成する。これを元にクローンのサーバーを幾つでも起動できる。ホスト名は起動時のパラメータとして付与でき、IPアドレスはVLANを指定することで、その中のサブネットから自動付与される。
インプリメンテーション
最初に作成したサーバーをマスターとしてイメージ・テンプレートを取得する。
ウェブ・サーバーの場合には、ローカル・ロードバランサーを準備しておく。 この場合のローカル・ロードバランサーは、HTTPやHTTPSなどのプロトコルに対して、サービス・グループを設定する。
プロビジョニング時に、ウェブ・サーバーの場合は、コンテンツのマスターから最新のコンテンツを引き込むことができるシェル・スクリプト等を準備する。 また、KVSの場合は、クラスタのメンバーとしてジョインするためのシェル・スクリプトを準備する。
これらのシェルは、プロビジョニング・スクリプトに登録しておき、サーバーのプロビジョニング時に簡単に指定できるようにする。
増設の必要性が生じた際に、イメージ・テンプレートから必要な数のクローンの仮想サーバーを起動し、プロビジョニング・スクリプトで自動初期化する。 ウェブ・サーバーの場合、ローカル・ロードバランサーの設定に増設した仮想サーバーを加える。
サブネットのIPアドレスが枯渇したら、VLANに新たなサブネットが自動追加されIPアドレスが割当られるため、これに対して管理スタッフが懸念する必要がない。
効果
クローンのサーバーを活用することで、サーバーの設定に関する人手を減らし、迅速な対応ができる。
マスターとなるイメージの変更管理を行い、熟成されたマスターイメージを再利用することで、サーバー構築の品質を高めることができる。
懸念事項・注意点
コンテンツのマスターとなるサーバーが、停止した場合、クローンサーバーの増設ができない。 このような事態を避けるため、信頼性の高いオブジェクト・ストレージに保存して、CloudFuseでコピーする方法も取れる。
コンテンツ管理のためのデータベースが、マスターサーバーで稼働している場合、データベースの接続先はマスターサーバーとする。
コンテンツの登録がある場合、必ずマスターサーバーで行いクローン側はコピーを取り込む。
参考資料
3.2 サーバーのクローンを作るには？
1.2.2 設定スクリプトの自動実行
1.5.1 仮想サーバーのOSバックアップを取るには？
3.3.1 ローカル・ロードバランサーを使うには？
5.8 Windowsのドライブとして利用するには？
5.9 Linuxにマウントするには？