FUJITSU Cloud Service K5
IaaS 設計・構築ガイド（デザインパターン・実装サンプル集）

Anti-Affinity パターン


要求事項

サーバを運用待機構成といった構成で分ける際に、複数の仮想サーバを確実に別々の物理サーバ上に配備することで、
K5内部で物理サーバ故障時の影響範囲を局所化するようにしたい、といった要求事項に対応するパターンです。



対応するK5デザインパターン概要

K5では、仮想サーバをサーバグループとしてまとめて登録し、そのサーバグループの挙動をポリシーとして指定することで、
複数の仮想サーバをどのように物理サーバ上に配置するかを指定することができます。

具体的には、サーバグループ内の仮想サーバ群がどのように物理サーバ上に起動されるかを、以下のポリシーで指定します。

ポリシー仮想サーバの配備
AffinityAffinityポリシーのサーバグループに登録された仮想サーバ群は、
可能な限り同一の物理サーバ上で起動されます。
Anti-AffinityAnti-Affinityポリシーのサーバグループに登録された仮想サーバ群は、
確実に別々の物理サーバ上で起動されます。

以下では、"Anti-Affinity" ポリシーで別々の物理サーバに仮想サーバを配備する例について記載します。



構造 (イメージ図)



実装サンプル

１．サーバグループ作成

　(1) サーバグループ作成
　　　サーバグループを作成します。
　　　以下のAPIに、設定項目(json)を設定し、実行してください。
　　　サーバグループが作成された際に表示される ID を、変数 ($GROUP_ID) に設定してください。

  • 設定項目(json)
項目
設定値
内容
$NAME"cdp_server_group"任意の名称
$POLICY"anti-affinity"別々の物理サーバに配備："anti-affinity"
同一の物理サーバに配備："affinity"
$AZ"jp-east-1b"アベイラビリティゾーン
AZ1："jp-east-1a"
AZ2："jp-east-1b"
  • 実行API

curl -s $COMPUTE/v2/$PROJECT_ID/os-server-groups -X POST -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type:application/json" -d '{"server_group":{ "name": "'$NAME'", "policies": [ "'$POLICY'" ], "availability_zone": "'$AZ'"}}' | jq .


　(2) サーバグループ確認
　　　サーバグループが作成されたか確認します。

  • 実行API

curl -s $COMPUTE/v2/$PROJECT_ID/os-server-groups -X GET -H "X-Auth-Token: $OS_AUTH_TOKEN" | jq .



２．仮想サーバ作成

　(1) 仮想サーバ作成
　　　仮想サーバを、サーバグループの設定を含めた API で作成します。

  • サーバグループの設定は、仮想サーバ作成の API に渡す json に、以下のパラメータを付与するだけです。
    $GROUP_ID は、前項の手順で、生成されたサーバグループの ID が設定されています。

"os:scheduler_hints": {"group": "'$GROUP_ID'"}


  • 設定項目(json)
項目
設定値
内容
$VM_NAME"anti-affinity-test01"仮想サーバ名
$IMAGE_REF_ID(OSイメージのID)K5で提供されるOSのイメージID
$FLAVER_ID"1101"CPUとメモリの組み合わせを示すフレーバーのID
1101：S-1
1102：S-2 等々
$VOL_SIZE"30"システムボリュームサイズ
$DEVICE_NAME"/dev/vda"デバイス名
$SOURCE"image"ボリューム元：image
イメージを利用しているため、imageを指定
(他にvolume、snapshot)
$DESTINATION"volume"接続先：volumeを指定
$ISDELETE"1"ボリュームの削除有無：1
インスタンス作成時に作成したボリュームを、インスタンス削除時に削除するかどうかを指定
0:仮想サーバ作成時に作成したボリュームを、仮想サーバ削除時に一緒に削除しない
1:仮想サーバ作成時に作成したボリュームを、仮想サーバ削除時に一緒に削除する
$INSTANCE_MAX"1"最大配備数
$INSTANCE_MIN"1"最小配備数
$NETWORK_ID(ネットワークID)配備先ネットワーク
$SG_NAME1"SG_name1"セキュリティグループ名
$SG_NAME2"SG_name2"
$GROUP_ID(生成されたID)サーバグループID
  • 実行API

curl -i $COMPUTE/v2/$PROJECT_ID/servers -X POST -H "X-Auth-Token: $OS_AUTH_TOKEN" -H "Content-Type: application/json" -d '{"server": {"name": "'$VM_NAME'", "availability_zone": "'$AZ'", "imageRef": "", "flavorRef": "'$FLAVOR_ID'", "block_device_mapping_v2":[ {"boot_index": "0", "uuid":"'$IMAGE_REF_ID'", "volume_size": "'$VOL_SIZE'", "device_name": "'$DEVICE_NAME'", "source_type": "'$SOURCE'", "destination_type": "'$DESTINATION'", "delete_on_termination": "'$ISDELETE'"} ] , "key_name": "'$KEYNAME'", "max_count": "'$INSTANCE_MAX'", "min_count": "'$INSTANCE_MIN'", "networks": [{"uuid": "'$NETWORK_ID'"}], "security_groups": [{"name": "'$SG_NAME1'"},{"name": "'$SG_NAME2'"}]}, "os:scheduler_hints": {"group": "'$GROUP_ID'"}}'

  • 仮想サーバが作成された際に表示される ID を、変数 ($VM_ID) に設定してください。

　(2) 仮想サーバ確認
　　　仮想サーバの作成状況を確認してください。
　　　仮想サーバの状態が "ACTIVE" となり、仮想サーバにログインできることを確認してください。

  • 実行API

curl -s $COMPUTE/v2/$PROJECT_ID/servers/$VM_ID -X GET -H "X-Auth-Token: $OS_AUTH_TOKEN" | jq .


　(3) サーバグループ確認
　　　サーバグループに、前項で作成された仮想サーバの ID が追加されたか確認します。

  • 実行API

curl -s $COMPUTE/v2/$PROJECT_ID/os-server-groups -X GET -H "X-Auth-Token: $OS_AUTH_TOKEN" | jq .



メリット・効果

Anti-Affinity パターンを利用した場合のメリット・効果は以下の通りです。

  • 複数の仮想サーバを、確実に別々の物理サーバ上に配備することで、
    K5内部で物理サーバ故障時の影響範囲を局所化することが可能



注意事項

  • 本パターンは2016年1月時点のK5(IaaS)で動作検証しています。

  • シングルAZでオートスケールを利用する等、シングルAZ内部で仮想サーバを複数稼働させる場合は、
    Anti-Affinityを使用しないと、物理サーバの障害で複数の仮想サーバが同時に停止してしまう可能性があります。

  • "専有インスタンス" 利用時は、Anti-Affinity設定は出来ません。



その他

マルチAZ構成の場合も Anti-Affinity 設定は可能ですが、 仮想サーバはAZごとに別の物理サーバに配備されているため、
Anti-Affinityを設定しなくても、物理サーバ故障時に他のAZの仮想サーバで業務継続が可能です。



関連資料

  • FUJITSU Cloud Service K5 マニュアル
    http://jp.fujitsu.com/solutions/cloud/k5/document/
    • サービスご紹介資料
    • IaaS 機能説明書
    • IaaS サービスポータルユーザーズガイド
    • IaaS APIユーザーズガイド
    • IaaS APIリファレンスマニュアル
    • IaaS HEATテンプレート解説書

(2016年1月検証)