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機能もあるのでサービス停止を回避しながらゾーン移設も可能です。

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

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

2016年11月22日火曜日

CentOS5のyumな環境でATS対応させた話

どうもtaka3110ことどんです。

今回は待った無しになっているATS対応の話です。
そもそもATS対応って何じゃい?という方は、こちらをご参照下さい。

簡単に言うと、AppleさんとこのIOSアプリからAppleさんが言うセキュリティに
準拠していないサイトは片っ端から弾きまっせ。覚悟しとき。
という宣告です。

ATSに対応する為には
-------------------
・ TLS ver 1.2以上であること
・ 以下のcipherに対応している事
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
・サーバ証明書はsha256でキーは2048bit長以上にする事
-------------------
というルールがあるらしい。

何が困ったってCentOS5系を運用しているサイトやゲームですね。
特に側ネイティブでやっているアプリなんて季節的にもCentOS5があったりするのでは?

CentOS5でATS対応するには、
・opensslをsrcからコンパイル
・apacheの最新版をsrcからコンパイル
しなければ対応出来ません。
(対応出来たよ!という方は教えて下さい・・・)
ちなみにopensslをsrcコンパイルしてmod_ssl作ればええやん的な安易な発想でしたが、
SSLCompressionの設定、ECDHEに対応していない等の罠があり結論無理でした。

yumの環境だと相当難儀な作業になります。
モジュール類、特にphpもソースコンパイルして対応となると、
もうね、それだけで面倒な作業。

という訳で、出来る限りyumでインストールされている現況を崩す事なく、
何とかATS対応出来ないかという事でやってみました。

aprを変更せずに、prefix指定でソースコンパイルすれば、
そのままyumで入れた同じモジュールを使えるのではないか説が沸きあがり、
実際にやってみたら使えたのでご紹介します。
(実際にやっても自己責任でお願いしますね・・・)

1.作業ディレクトリ作成
解りやすく作業する為に作業ディレクトリを作ります。

mkdir /root/src
cd /root/src

2.ソースゲット
最新版のソースをゲットします。
元々2.2系だったので、2.2系の最新とopensslの1.0.1の最新を入れます。

wget http://ftp.jaist.ac.jp/pub/apache/httpd/httpd-2.2.31.tar.gz
wget https://www.openssl.org/source/openssl-1.0.1u.tar.gz

3.opensslのインストール
あくまでmod_sslを作るためだけのopensslにしたいので、
prefixを指定してインストールします。
#config時の"-fPIC"は入れても入れなくても大丈夫です。入れた場合、ソースの書き換えが一部必要になります。

tar xzvf openssl-1.0.1u.tar.gz
cd openssl-1.0.1u
./config --prefix=/usr/local/openssl1.0.1 shared
make
make install
cd ..

4.apache
apacheについても既存環境を汚さないようにprefixを指定してインストールします。
ちなみにenable類は無くても大丈夫だと思います。何か、念のためやりました。

tar xzvf httpd-2.2.31.tar.gz
cd httpd-2.2.31
./configure --prefix=/usr/local/httpd-2.2.31 \
--enable-dav=shared \
--enable-dav-fs=shared \
--enable-dav-lock=shared \
--enable-proxy=shared \
--enable-proxy-connect=shared \
--enable-proxy-ftp=shared \
--enable-proxy-http=shared \
--enable-proxy-balancer=shared \
--enable-proxy-ajp=shared \
--enable-rewrite=shared \
--enable-ssl=shared \
--enable-mem-cache=shared \
--enable-so \
--enable-modules=all \
--enable-mods-shared=all \
--with-ssl=/usr/local/openssl1.0.1
make
make install
cd ..


ここまで出来れば後はapacheのmoduleと起動スクリプト類を入れ替えるだけです。
ちなみに同じようなCentOS5が他にもある場合、ここで作ったディレクトリを配布すれば、
いちからコンパイルする必要は無いです。
/usr/local配下にopenssl1.0.1とhttpd-2.2.31ディレクトリを置いてやればokです。


適用作業はこんな感じでやりました。

5.初期コンフィグのバックアップ
戻せるようにしておきましょう。

mv /usr/local/httpd-2.2.31/conf /usr/local/httpd-2.2.31/conf.org
mv /usr/local/httpd-2.2.31/modules /usr/local/httpd-2.2.31/modules.org

6.既存モジュールのcopy
yumで入れたモジュールをコピーします。
#パスは64bitの場合です。

cp -rp /usr/lib64/httpd/modules /usr/local/httpd-2.2.31/

7.既存コンフィグのコピー
既存のコンフィグを適用させましょう。

cp -rp /etc/httpd/conf /usr/local/httpd-2.2.31/
cp -rp /etc/httpd/conf.d /usr/local/httpd-2.2.31/
cp -rp /etc/httpd/common /usr/local/httpd-2.2.31/

8.設定ファイル類のディレクトリ構成設定
運用性を考えて同じディレクトリ構成にしておきましょう。

mv /etc/httpd /etc/httpd.org
ln -s /usr/local/httpd-2.2.31 /etc/httpd

9.起動ファイルの変更
戻せるようにしておくのと、tab効きするようにしておきましょう。

mv /etc/init.d/httpd /etc/init.d/httpd.org
chmod -x /etc/init.d/httpd.org
ln -s /usr/local/httpd-2.2.31/bin/apachectl /etc/init.d/httpd
mv /usr/sbin/httpd /usr/sbin/httpd.org
chmod -x /usr/sbin/httpd.org
ln -s /usr/local/httpd-2.2.31/bin/httpd /usr/sbin/httpd

10.mod_sslのモジュールのみコピー
mod_sslは今回コンパイルしたものを使います。

cp -pi /usr/local/httpd-2.2.31/modules.org/mod_ssl.so /usr/local/httpd-2.2.31/modules/

11.logやrunフォルダの設定
logフォルダは引き継ぐようにしておきます。

mkdir /etc/httpd/run
mv /etc/httpd/logs /etc/httpd/logs.org
ln -s /var/log/httpd /etc/httpd/logs

12.アップデートしたopensslをmod_sslが読みに行く為の設定
最後にmod_sslがprefixしたopensslを読みに行けるようにしておきます。

echo "/usr/local/openssl1.0.1/lib" >> /etc/ld.so.conf
ldconfig

以上で完了。
古いapacheが上がっていればpkill httpdで落としてやれば、
普通に新しいapacheを上げられる筈。

これで構築したサイトを以下で見てみるとATS対応している筈。
https://www.ssllabs.com/ssltest/


ここまででとりあえず一時しのぎ的にATS対応出来たとしましょう。
でもね、そもそも論としてCentOS5を使い続けるってどうなのよ?
という疑問を投げかけざるを得ない。

という訳で、取り急ぎ時間が出来たという事で、
しっかりと計画してリプレースしましょう。

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












一応、、、、もとにもどす手順も置いときます。

rm /etc/httpd
mv /etc/httpd.org /etc/httpd
rm /etc/init.d/httpd
mv /etc/init.d/httpd.org /etc/init.d/httpd
chmod +x /etc/init.d/httpd
rm /usr/sbin/httpd
mv /usr/sbin/httpd.org /usr/sbin/httpd
chmod +x /usr/sbin/httpd

2016年9月20日火曜日

YAMAHAのルーターで存在しないNWを使ってVPNする話

どうもtaka3110ことどんです。

最近、YAMAHAのルーターと戯れる事が多かったので、
少しメモ代わりに書いておきます。

題名だけ見ると大それたというか、謎めいた感じですが、
簡単に言えばNATです。はい。
ただ、双方向NAT(TwiceNAT)のドキュメントはありますが、
単方向NATでマスカレードしないのはあまりなく、でも結構使う機会がある。
というところでブログネタにした訳です。

最近ではフレッツVPNなどで店舗間でも割と簡単にフレッツ網を使ったVPNがはれます。
店舗間データのやり取りをセキュアに行いたい等、結構使う機会はあると思います。
例えば、本店と店舗のNWが全く同じ場合は、前記のTwiceNATを用いれば良いですが、
(TwiceNATの設定例:http://jp.yamaha.com/products/network/solution/vpn/connect/twice_nat/ )
本店が「このNWで接続して下さい。」と払い出されて、店舗側が違うNWになっている場合。
これって、店舗側のNWを総入れ替えするか、NATするかの2択な訳で。
やれ工数だの改修だのを考えると、結論NATになる訳です。

ただ、もう1台ルーターを置いてやるのが綺麗なやり方。
存在しないNWではなく、存在するNWを作ってしまう。
本社ルーター --> 店舗ルーター(NEW) -(払い出しNW)-> 店舗ルーター
という感じで払い出しNWを作ってしまって、そこのIP帯でNATさせる。
というのが割と綺麗なやり方だと思います。
が、そんなポコスカとルーターを買うという訳にもいかないと思いますし、
出来るので、1台でやってしまいましょうと。

そうすると、やり方としてはざっと考えて2つあって、
・ セカンダリIPをつけてルーティングさせてしまう。
・ 払い出しNWのIPでNATさせてしまう。
という2つかと。

で、もう存在はしてないけど、払い出しNWのIPでNATして通信出来れば良い。
という事で、今回はそんな感じの話です。

本店から払い出されたNWは10.1.10.1/24
基幹に接続するコンピュータのIPは接続元制限により10.1.10.254のみ許可。
例えばストコンが基幹にデータを送る場合は上記IPで送る必要がある。
というような感じ。


構築するNWはこんな感じです。


















で、どう構築するかって話になるんですが、
先のTwiceNATのページのreverseの部分を削除すればいいだけ。
というより、TwiceNATも存在しないNWを間に挟んで同じNWを通信させてるイメージなので、
それと同じことをしてやれば良いと。

書き方も割と単純に、ほんとreverseを削除しただけのこんな感じで通ります。
(ISPの部分やVPN認証、フィルタ等の設定は別途必要)
---
#ルーティング
ip route 172.11.0.16/32 gateway pp 1
ip route 10.20.0.0/16 gateway tunnel 1

#NAT
nat descriptor type 1 masquerade
nat descriptor masquerade static 1 1 172.11.0.16 udp 500
nat descriptor masquerade static 1 2 172.11.0.16 esp
nat descriptor type 2 nat
nat descriptor address outer 2 10.1.10.1-10.1.10.254
nat descriptor static 2 1 10.1.1.254=192.168.1.50 1

pp select 1
ip pp address 172.11.0.1/32
ip pp nat descriptor 1

tunnel select 1
ip tunnel nat descriptor 2
---

やっぱり存在しないNWがあって、途中でNATにより処理する。
というのはあり得る話なんですが、少し気持ち悪いなぁ。と思うのは私だけかしら。。

割と設計的にはあり得る話ですが、ググってもなかなか出てこないので、
書いてみました。

というわけで、よいクラウド?構築を。

2016年8月27日土曜日

IDCFクラウドの追加NWの注意点

最近、IDCFクラウドの追加ネットワークでちょっとしたハマり方をしたのでメモ。


IDCFクラウドはネットワークを追加する事が出来ます。
NICも独立するので、インターネット側のNWとは別にしてVPNのネットワークを作ったり、
DBの通信にしようしたり、Heartbeat専用のネットワークを作ったり。
まぁ、いろんな設計が無停止で柔軟に出来るようになっています。
ネットワーク追加も従量課金で20円/時間で課金され、1か月1万円が課金上限になるシステムです。

で、今回は既存の環境から移設というところで構築したのですが、
色々な制限があり再設計する事になりました。
結論から言うと、追加ネットワークを使った設計をする時は、
実際に追加ネットワークをしてから設計するか、IPを柔軟に変更できる設計にしておくと良いです。
例えばDBと接続する際にIP指定で許可している場合、許可設定の変更をしたり、
そもそもDBのIPが変更しなければならない可能性があります。
同じハマり方をしないようにご注意というところで。


1.システム予約IPがある
後方20個のIPはシステム予約として使用出来ないIPになっています。
例えば、デフォルトで以下NWが指定されます。(もちろん変更可能)
192.168.0.0/21
上記のうち、192.168.7.235~254はシステムで予約して使用不可能になっています。
従って、後方20IPを使用したIP設計は見直しになります。

2.CIDRが/24~/21のみ
CIDRは/24~/21でしか使用できません。/25、/26のNWは作れません。
従って、/24よりも分割されたNWは設計見直しになります。

3.仮想ルーターにIPが自動で採番される
仮想ルーターにIPが自動で採番されます。これはシステム予約IPに含まれていません。
例えば、192.168.0.0/21のNWで構築した場合、どこに採番されるか解りません。
基本的には192.168.0.1が使用されるようですが、2や3が採番される可能性もあります。
仮想ルーターのIPは使用出来ないので、こちらも被った場合は設計見直しになります。


ご察しの通り、3に見事にはまりまして。
移設前はWebサーバーを192.168.0.1に割り振っていたのですが、
移設したところ仮想ルーターに192.168.0.1を取られてしまい採番出来なくなりました。
今回はteslaからnewtonへのゾーン間移設だったのですが、
移設前と移設後で仮想ルーターのIPが変わった為、このようなハマり方をした次第です。

もし、セキュリティ的にもしばりが無いようであれば、
192.168.0.0/24のNWを作る場合、
192.168.0.0/23のNWを作って、192.168.1.1~254の範囲でIP設計をすると良いと思います。
どうしても/24で作成する場合、念のため、192.168.0.1~10は使用しない等で回避が出来るかと思います。


ちなみに、NICは追加/削除をしていくとデバイス名が変わります。
CentOS7であればさほど困らないかもしれませんが、、

CentOS6系でNICを追加/削除してeth1のつもりがeth2や3になってeth1に戻したいという場合、
udevを修正する事で変更する事が可能です。
以下ファイルにNICの情報が記載されています。
/etc/udev/rules.d/70-persistent-net.rules
上記ファイルで不要なNIC情報を削除し、最後に割り当てられているNICのnameをeth1にします。
udev rulesの反映を行う為に以下コマンドを実行します。
start_udev
これでeth1に戻ります。
あまり使う機会は無いと思いますが。。

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

2016年7月11日月曜日

クラウドの勉強会をやる際に注意するポイント

最近、クラウド系の勉強会をやる機会が多いどん斉藤ことtaka3110です。

初級~中級、上級、テスト対策、いろいろとやります。
非エンジニア向けのクラウド勉強会などもやったりします。
ベンダーフリーで使うクラウドは問わないので、こんな勉強会やってよ!など、
ご依頼はtaka3110までご連絡頂ければ打ち合わせ/企画から一緒にやります。

さて、宣伝はこの辺にして。。
クラウド系の勉強会、特にハンズオンの勉強会をやるときに注意するポイントが結構あります。
今回、実際にハマるポイントを書こうと思います。

① 上限の確認
 複数人でやる場合、サーバーの上限やIPの上限等、
クラウドが定める上限値に達していないか確認をします。
上限以上を使用するならば、上限の緩和申請をサポートにしましょう。
殆どのクラウドで上限の緩和が可能です。
遅くても3営業日前には申請をするようにしましょう。

② 同じアカウント内で同時実行時のデフォルトパラメーター確認
 同じ資料を見ながら行った場合やデフォルトの値を使用する場合に、
値がすべて同じになってしまいエラーが続発する可能性があります。
特に同じアカウントでやる場合(AWSでIAM使用する場合も含む)は、
ユーザー名を追加する等、ユニークな値を入力してもらうようにしましょう。
例:AWSのサーバー起動時のセキュリティグループ等

③ リージョンの確認
 これもハンズオンをやる時にたびたび出る問題です。
多くのクラウドはリージョンの変更を行っても殆ど画面上に変化はありません。
リージョンを指定して、ログインした際に確認するように促します。

④ OS選択時のマイナーバージョンの確認
 OSによってはマイナーバージョンが違うだけでログイン方法が変わるものがあります。
(管理者ログインが禁止されているものなど)
テンプレートやAMI等を選んでもらう際にはID等で解るようにしておきます。

⑤ 削除漏れの確認
 削除したと思ってDiskが残っていたり、スナップショットが残っていたりする事があります。
勉強会が終わったら、早めにリソース状況の確認を行って削除するようにしましょう。

⑥ サービスとアカウントを分ける
 これが一番恐ろしいんです!
社内の場合、同じアカウント内にユーザーを作成して多人数で実施するケースが多いと思います。
サービス提供をしているサーバーがある場合は間違えて停止や削除等の誤操作をする可能性があります。
結構触ってもらいたい場合、管理者に近い権限を付与する事になります。
教える側も緊張するので、なるべくサービスアカウントではなく、別途アカウントを取得するようにしましょう!
いたしかたない場合はリージョンを変更する等で容易に触れられない環境を作りましょう。


クラウドは便利なんですけど、便利だから簡単に出来るのではなく、
最低限の準備は必要という事ですね。

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

2016年7月1日金曜日

IDCFクラウドのDisk領域を3GBにしたテンプレート

Disk領域3GBのCentOS6.8テンプレートを作りました。

light.S1ならば1か月稼働で260円程度(2016/06/30現在)になります。
落としておいても1か月60円程度ですので、気軽に複数台の検証サーバとして使えるかと。
空き容量は約1.4GB程度ありますので、
色々と試せる環境かと思います。
cloudstack-apiもインストール済みなので、
ちょっとしたAPIテストや、検証などにご使用ください。

またコンテンツ領域を追加Diskにしてlogローテを行い、
そのlogをオブジェクトストレージ上に保存する事で、
コンテンツ領域のみをスナップショットでバックアップしながら、
無償で使える50GBのオブジェクトストレージを有効活用するなんて事も出来るかと思います。

いろんな用途で試して頂ければ幸いです。

自分の場合はab(負荷テスト)用として使ったり、踏み台として利用したり。
使わない時は落としておくような、ちょっとした事に使ってます。

要望やバグ連絡は本ブログにコメント頂ければ幸いです。
ちなみに本テンプレートを元に更新してコミュニティテンプレートをアップ頂いて構いません。

詳細
----
OS:CentOS 6.8
インストール:Baseシステム
その他:
・VMW関連
vmware-tools-esx-nox
vmware-tools-esx-kmods
vmware-tools-vmxnet3-common

・IDCFクラウド関連
パスワード変更ツール
認証鍵変更ツール
cloudstack-api(v0.10.2)

・開発関連
pip(8.1.2)
git(1.7.1)
及び上記解決の為のソフトウェア

セキュリティ:
iptables off
ip6tables off
selinux Disable
----

2016年6月30日木曜日

IDCFクラウドでテンプレートのエクスポートロックを解除する話

どうも、taka3110ことどん斉藤です。

IDCFクラウドはテンプレートをエクスポートが出来ます。
ただしISOから作成した仮想マシンのテンプレートは、
ライセンスの問題もあってエクスポートが出来ないようになっています。

オープンソースの場合はサポートに申請をすれば、
すぐにエクスポートロックの解除対応をしてくれます。

こんな感じで申請します。
-----
CentOS6.8を使用して作成した以下テンプレートについて、
エクスポートロックの解除をお願いします。
テンプレートID:[テンプレートIDを記入]
-----

そうすると中の人が確認をしてくれます。
問題無ければエクスポートロックの解除をした旨連絡が入ります。

公式のテンプレートはDiskが15GBで縛られている為、
サーバーを止めていても月額で300円掛かってしまうんですよね。
自分は3GB程度あれば良いので、ISOから作成しています。

エクスポートロックが解除されるとリージョン/ゾーン間でコピー出来るようになりますし、
コミュニティテンプレートの公開も可能になります。
エクスポートロックが解除されたテンプレートは、そのままコミュニティテンプレートには
出来ません。
一旦、エクスポートのURLを発行して、そのURLを使ってテンプレート作成をする事で、
コミュニティテンプレートが作れるようになります。ここは謎仕様です。
(発行されたURLはhttps://~ですが、テンプレート作成時はhttp://~に書き換えれば読み込めます)

それでは、良いクラウド構築を!


2016年5月24日火曜日

IDCFクラウド「MORIO Dojo」に認定してもらったはなし

ブログを書くのが苦手なtaka3110こと、どん斉藤です。

なんでブログって書けないんですかね。
これ書こう、あれ書こう、って思って休日を迎えるんですけど、
結果的に家族サービスや競馬やってるんですよね。
ITへの愛が足りないのか。愛が。

という訳で、環境から作ろうという事でブログを書くきっかけを作りました。
IDCFクラウドで新しくアンバサダープログラムが始まりました。
その名も「MORIO Dojo」(モリオ道場)
IDCFクラウドの使いっぷりやコミュニティでの活躍っぷりによって、
段位認定してくれるというシステム。

このプログラムに参加すると、クローズドのコミュニティに参加して、
IDCFクラウドに長けたいろんな方々と会話が出来たり、
限定イベントに招待してもらえたり、プレゼントもらったり出来るそうです。

段位自体は空手みたいな感じで帯色によって認定が分かれてます。
段位認定の条件をクリアすれば次の段位へ!という形で、
最高段位のMORI帯を目指す。という感じのようです。
ゲーミフィケーション的な感じで面白いですね。

私もコミュニティを運営している端くれとして青帯で認定依頼をしたところ、
認定してもらえた次第です。
MORI帯までの道のりとして、一番の山場は3か月間、1か月に1度はIDCFクラウドの記事を書く。
基本、このブログはIDCFクラウドネタが多いのですが、連続性が無い、というか、
ブログを続けて書けない人なので、これをモチベーションにしてブログを続けてみようと。
そういう次第であります。
さて、私のクリア状況ですが、

白帯:
◎PCにMORIOステッカーを貼ってる
◎個人で発信する媒体を持っている
青帯:[いまここ]
◎ユーザー会への参加
○クローズドコミュニティでの積極的な発言
茶帯:
×IDCFクラウドのバナーを貼っている
△IDCFクラウド関連の記事を投稿(1か月に1回程度)
黒帯:
×IDCFクラウド関連の記事を3か月連続で投稿
◎お客様の声への協力
MORI帯:
◎ユーザー会を運営
×コミュニティテンプレートを公開

という訳で、茶帯は直ぐいけそうですが、黒帯は3か月後になりそう。
飛び級出来るなら3か月後にはMORI帯になれるんじゃないかと。

白帯については割と直ぐに認定されそうです。
青帯ですが、ユーザー会への参加があります。
東京では6月28日(火)にユーザー会を予定してますので、
こちらもチェキっといてもらえれば来月には青帯になれると。
ユーザーコミュニティ

というか、ユーザーコミュニティを作ってしまえばMORI帯の条件をクリア出来ます。
初めての運営でもmeetup運営メンバーに優しくサポートしてもらえます。
作りたいけどどうすんの?とか、やりたいから手伝って!
という方は以下の問い合わせから連絡くれればお手伝いします。

MORIO道場で検索すると奈良のよくわからん公共施設がヒットするので、
検索するときはMORIO Dojoで検索しましょう。
もしくは以下URLからどうぞ。

早速6月に限定イベントやるそうなので、登録はお早めに~。