2016年12月19日月曜日

IDCFクラウドでゾーンを移設するメリットと方法

※本記事はIDCF Cloud Advent Calendar 2016に寄稿しています。

どうも。どんことtaka3110です。
前回はゾーン別のスペックについて書いてみました。
今回はゾーン移設を実際にやってみます。
手順を書いた長い記事ですので、面白いことは書いてません。あしからず。。

メリットについては前回のブログで書いた通り、
スペックが違う為、初期のゾーンから移設するという選択だけで、
性能アップが見込めます。

今回、wordpressとメール的な環境を想定してみました。
移設元は「メールサーバー + Webサーバー」(Web+DB)という内容です。

前提としては、
----
移設元環境
・IDCF提供のテンプレートを使用して構築されている
・仮想ルーターIPを使用している
・Webサーバーとメールサーバーに使用している
----
としています。

やり方はいくつかあります。
このブログでも紹介しましたが、rsyncでOSより上をまるっと移設する方法や、
1から構築してデータのみを移設する方法もあります。

今回はテンプレートファイルを作成し、それをリージョン移設して構築したいと思います。
今回はteslaから東日本2のluxに移設します。

極力ダウンタイムを減らしたいので、
Webについてはsorryサーバーを表示させ、メールはセカンダリを指定してみます。
今回の記事でもsorryサーバーとセカンダリメールサーバーの構築をしたいと思います。
移設前にはスムーズに作業、確認を行うためにDNSのTTLを下げておきましょう。
最低でも600以下にしておく事をお勧めします。

セカンダリメールサーバーを作成してそちらに向けるメリットとしては、
こちら側の意図でメールの再配信が出来るところにあります。
メールサーバーへの疎通ができない場合、送信元がリトライを行います。
リトライの回数、秒数については送信元によって違います。
セカンダリメールサーバーを用意しておくと、送信元はメール送信を完了し、
セカンダリメールサーバーで再送処理をする形になります。
作業完了後にセカンダリメールサーバーで再送処理をする事で、
移設後直ぐにメールサーバーを落としていた間のメールが届く形になります。
常時運用ではなく、今回はスポット的に使用しますが、とても簡単に構築出来ます。
なお、サービスを停止してからテンプレートを取得する手順を踏む為、
送信だけ行っている環境であればセカンダリメールサーバーの構築は今回必要ありません。

セカンダリメールサーバの構築時にluxのIPを使用するので、
移設元がIPを取得しているならば、先にIPの取得をしておきましょう。
(この記事では仮想ルーターのIPを使用します。)
また、ポートフォワードの設定も移設しておきましょう。

今回の流れ
0.移設先のIP取得とポートフォワードの設定
1.sorryサーバーとセカンダリメールサーバーの構築
2.DNSの登録とポートフォワードの設定変更
3.スナップショット、テンプレートの作成
4.テンプレートの移設
5.テンプレートから構築
6.移設後の確認
7.DNSの変更
8.セカンダリメールサーバーの再配送
9.後片付け
大体、15GBであれば1時間程度で完了する作業です。

先ずはsorryサーバー+セカンダリメールサーバーを作ります。
移設元の同じゾーンに仮想マシンを立ち上げます。
今回はCentOS6.8を選択して構築したいと思います。

仮想マシンが立ち上がったらIPアドレスを取得します。
IPアドレスを取得したら今回立ち上げた仮想マシンにNATの紐づけをします。
NATの紐づけはNATボタンから対象サーバーを選択して有効化するだけです。
この対応で全てのポートがNAT設定した対象サーバーに向けられます。
(もちろんポートフォワードでも構いません)

FWにはsorryサーバーとセカンダリメールサーバー用の許可設定を追加します。
先ずはsshのport22をMyIP等、作業環境から許可し、
httpのport80、smtpのport25をAny(0.0.0.0/0)で許可します。
(httpsのアクセスが必要な場合は443も許可しましょう)

上記まで完了したらsshでサーバーにログインしましょう。

Webサーバーを構築します。
# yum -y install httpd
# /etc/init.d/httpd start

下記にsorryページを配置しましょう。
/var/www/html/index.html

この状態で"http://取得したIPアドレス/"にアクセスして、
sorryページが表示されればOKです。

次にセカンダリメールサーバーを作成します。
既にpostfixはインストール済みになっているので、設定変更のみ行います。
# vi /etc/postfix/main.cf
----

以下をlocalhostからallへ変更
----
inet_interfaces = all
----

最終行に以下を追記
----
transport_maps = hash:/etc/postfix/transport
relay_domains = ドメイン名
----

# vi /etc/postfix/transport
以下を追記
----
ドメイン名 smtp:移設先サーバーのIP
----
例)ドメイン名がtest.orgで移設先サーバーが210.140.171.1だった場合
test.org smtp:210.140.171.1

設定を反映します。
# postmap /etc/postfix/transport
# /etc/init.d/postfix restart

以上でsorryサーバーとセカンダリメールサーバの構築は完了です。

次にセカンダリメールサーバー用にDNSを設定しましょう。
今回取得したsorryサーバー用のIPアドレスをAレコードで指定します。
mail2等、解りやすい名前で構いません。
次にMXレコードを今のものよりも大きい優先度で設定します。
例)今が10であればセカンダリは20

これでDNSが浸透すればセカンダリメールサーバの設定は完了です。


ここからは移設の作業になります。
ダウンタイムにある程度の許容があれば、データの不整合等もなくなるので、
この時点でsorryサーバーに切り替えてしまいましょう。
ダウンタイムに許容が無い場合は、sorryサーバーへの切り替えは最後に行い、
DNSの浸透を待って新しいサーバーへ同期を行いましょう。

今回はこの時点でsorryサーバーに切り替えを行う手順を取ります。
この記事ではhttp、httpsをsorryサーバーに切り替えます。
既存のサーバーのポートフォワードを一旦削除し、sorryサーバーへ向けます。
※既存のサーバーがNATでしたら別のIPを取得し、ポートフォワードで設定をし、
 そちらにDNSを向けて対応しましょう。

移設元サーバーにログインします。
既にサービスはsorryサーバーの方を向いている事を確認し、
各サービスを止めます。
# /etc/init.d/httpd stop
# /etc/init.d/mysqld stop
# /etc/init.d/postfix stop

ここからサーバーをコピーする作業を行います。
テンプレートを作成する前にnetwork deviceの情報を削除します。
# rm -f /etc/udev/rules.d/70-persistent-net.rules
また、Disk追加をしている場合は、fstabで追加Diskの行をコメントアウトしておきます。

上記が完了したらスナップショットを取得します。
スナップショットは
仮想マシン⇒(対象の仮想マシン名)⇒ボリューム⇒右下のボリューム操作へをクリック
表示されるボリューム名をクリックし、スナップショット⇒スナップショット作成で取得できます。

スナップショットが取得出来たら、スナップショットを確認します。
ステータスがBackedUpになっていればスナップショットの取得完了です。
スナップショットからテンプレート作成をクリックします。
テンプレート名やOSタイプを選択し、作成するをクリックします。

作成できたテンプレートをエクスポートします。
テンプレートから作成したテンプレートをクリックし、エクスポートをクリックします。
URLを発行するボタンが表示されるのでクリックします。
※生成中の間は他のページ等に遷移しないように注意してください。

テンプレートのURLが表示されるのでテキスト等にコピーをしておきます。

ここまで出来たら移設先の東日本2にページを切り替えます。

コンピューティングのテンプレートからテンプレート作成ボタンをクリックします。
テンプレート名~OSタイプまでを入力します。フォーマット以下は特に変更は不要です。
URLは先ほどコピーしたURLのhttpsの部分をhttpにして貼り付けます。
全て入力したらテンプレートを作成するボタンでテンプレートを作成します。

上記テンプレートを使用して仮想マシンを作成します。
今回の記事ではセカンダリメールで転送先指定をしているluxを指定しているので、
ゾーンはluxを使用します。
また、SSH keyは元のサーバーと同じものを使用します。
アップロードをクリックし、移設元サーバーで以下で表示される内容をコピーしましょう。
# cat /root/.ssh/authorized_keys

上記入力が完了したら仮想マシンを作成します。

仮想マシンにログイン出来る事を確認したら、
立ち上がっていないサービスが無いか確認しましょう。

※ログイン出来ないという時は、udevのルールが残っている可能性があります。
 コンソールからログインして削除をしてrebootしましょう。

これでサーバー側は完了です。

最後にDNSを新しいサーバーへ向けなおします。

DNSが浸透をした事を確認したら、sorryサーバーにログインし、
postfixの溜まったデータを再配送します。

# postfix flush

以下コマンドでqueueが空になっている事を確認しましょう。
# postqueue -p
Mail queue is empty

上記が完了したら、sorryサーバーは削除してしまいましょう。
旧サーバーも停止してしまいましょう。
データについては何かあった際に使う可能性がありますので、
念のため2~3日についてはサーバーはそのまま残しておく事をお勧めします。

以上で移設完了です。お疲れ様でした。

さて、画像等を使わないで文字だけでつらつらと書いてしまい、
解りづらい部分もあったかと思います。
こんなところにハマった。とか、こういうのはどうやってやるの?
質問等があればご連絡ください。
また、ユーザー会もありますので、ぜひ参加して聞いてみて下さい。

それでは、よいクラウド構築を。

2016年12月4日日曜日

IDCFクラウドのゾーンから見る性能強化と進化

※本記事はIDCF Cloud Advent Calendar 2016 Advent Calendar 2016に寄稿しています。

どうも。どんことtaka3110です。

今回は久しぶりにIDCFクラウドについてです。
東日本に新しいリージョンがリリースされました。
これでリージョンは3個、ゾーンは10個となった訳ですが、
どれを使っても同じという訳ではありません。
という訳で、今回はゾーンについて振り返りながら性能を考えてみたいと思います。

まずはどんなゾーンがあるのか。

  ゾーン リージョン リリース
1 tesla※ 東日本 2014/10
2 pascal 東日本 2015/4
3 henry 東日本 2015/6
4 joule 東日本 2015/10
5 augusta 西日本 2015/11
6 radian※ 東日本 2016/3
7 newton 東日本 2016/7
8 monstera 西日本 2016/8
9 weber 東日本2 2016/11
10 lux 東日本2 2016/11

※は現在新規アカウントでは追加不可能のようです。

約2年で10なので、2.4か月に1ゾーンという形で増えています。
割と良いスピードで増えていますね。

2015年11月のaugusta以降は全てオールフラッシュディスクでの提供となっています。
(西日本、東日本2はオールフラッシュリージョン)
したがって、Disk性能がaugustaから飛躍的に上がっています。

性能だけが違うのかというと使えるサービスにも違いがあります。
例えばGPUインスタンスを立ち上げるには現在は東日本2になります。

ゾーン別の対応インスタンス

  ゾーン HighIO GPU
1 tesla※ highio.5XL128のみ 非対応
2 pascal 全て可 非対応
3 henry highio.5XL128のみ 非対応
4 joule 全て可 非対応
5 augusta 全て可 非対応
6 radian※ 全て可 非対応
7 newton 全て可 非対応
8 monstera 全て可 非対応
9 weber highio.3XL128のみ 対応
10 lux highio.3XL128のみ 対応


HighIOインスタンスに一部違いがあります。
また、GPUインスタンスは現在(2016/12/03現在)は東日本2リージョンのみの対応です。

ゾーンで違うのはこれだけではありません。
CPUの型も違います。newton以降から新しいCPUを搭載したマシンになっています。
light.S1は以下のようになっています。(タイプによってCPUが変わる場合があります。)

  ゾーン CPU
1 tesla※ Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
2 pascal Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
3 henry Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
4 joule Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
5 augusta Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
6 radian※ Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
7 newton Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz
8 monstera Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz
9 weber Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz
10 lux Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz

ここまで見てお分かり頂いたかと思いますが、
augusta以降からフラッシュディスクになり、newton以降からCPUが新しい型になっている為、
初期のゾーンと一番新しいゾーンでは、かなりの性能差が出ます
勿論、値段が変わらないので新しいzoneを使った方が断然コストパフォーマンスが高くなります。


言葉よりも数値で見た方が解りやすいと思います。
light.S1で全ゾーンをhdparmで比較するとこうなります。

  ゾーン cached reads buffered disk reads
1 tesla※ 8706.18 MB/sec 275.83 MB/sec
2 pascal 8336.05 MB/sec 264.62 MB/sec
3 henry 8823.00 MB/sec 204.79 MB/sec
4 joule 8419.01 MB/sec 290.63 MB/sec
5 augusta 8823.96 MB/sec 314.37 MB/sec
6 radian※ 8593.79 MB/sec 249.83 MB/sec
7 newton 10150.15 MB/sec 316.51 MB/sec
8 monstera 9981.35 MB/sec 389.55 MB/sec
9 weber 10436.24 MB/sec 403.65 MB/sec
10 lux 10395.61 MB/sec 411.82 MB/sec

augusta以降はフラッシュディスクになっている為、buffered disk readsが性能強化されており、
newton以降はcpuが強化されているのでcached readsが増えています。
しかしながらradianがスペックの割に性能が出ていません。
勝手な想像ですが、恐らくは東日本で初めてフラッシュディスクになったゾーンですので、
仮想マシン数が多いのではないでしょうか。そういった理由も新規で選択出来なくなっている理由でしょう。
新しくIDCFクラウドを契約する方は特に気にする理由は無さそうです。
古くから使用しているユーザはサポート等に現状厳しいゾーンを聞けば答えてくれると思います。きっと。ええきっと。


さて、より分かりやすく性能を見るためにWEB2層のアプリケーションで確認してみます。
実際にlight.S1へコンテンツを載せてWRSで比較してみると以下のようになります。
WRSとはデフォルトの状態でwordpressにabをかけて比較したものです。

  ゾーン ab -n 1 -c 1 ab -n 10 -c 10 ab -n 100 -c 10
1 tesla※ 6.30 [#/sec] 6.44[#/sec] 2.11[#/sec]
2 pascal 6.71 [#/sec] 6.3[#/sec] 2.07[#/sec]
3 henry 6.38 [#/sec] 7.12[#/sec] 2.13[#/sec]
4 joule 6.60 [#/sec] 6.56[#/sec] 2.1[#/sec]
5 augusta 7.47 [#/sec] 7.02[#/sec] 2.16[#/sec]
6 radian※ 6.63 [#/sec] 5.84[#/sec] 2.08[#/sec]
7 newton 8.54 [#/sec] 8.03[#/sec] 2.65[#/sec]
8 monstera 9.72 [#/sec] 9.38[#/sec] 2.79[#/sec]
9 weber 9.98 [#/sec] 9.54[#/sec] 2.99[#/sec]
10 lux 9.87 [#/sec] 9.56[#/sec] 2.82[#/sec]

何もしなくても、初期のteslaやpascalと比べて、
最新ゾーンのweber、luxは1.5倍程度の性能差が出ています。
勿論、まだリリース直後でユーザーが少ないというのも大きな要因ですが、
newtonで見てみても大分性能差が出ている事が解ります。

ちなみにab -n 100 -c 10だけ値が低いのは、
light.S1のCPUリミッター(0.8GHz)によるものです。
light.S1は0.8GHz相当という触書になっていますが、直ぐにCPUリミッターが掛かる訳ではありません。
上記表の通り、そこまでアクセス数が多くないサイト等であれば、2.4GHz相当で使用出来ます。

新しいゾーンが出ると性能が強化されて更に進化していくIDCFクラウド。
AWSではファミリーの世代という形で性能強化されていきますが、
IDCFクラウドでは現状、ゾーン毎に進化をしていきます。

上記のように性能が強化されるのでtesla等、旧ゾーンで性能が足りなくなってきたと感じたら、
ゾーン移設を検討するのも1つの手です。
複数台構成であれば、GSLB機能もあるのでサービス停止を回避しながらゾーン移設も可能です。

次回は旧ゾーンから新ゾーンに移設する方法をご紹介しようと思います。

それではよいクラウド構築を。