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

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

IDCFクラウドはネットワークを追加する事が出来ます。
NICも独立するので、インターネット側のNWとは別にしてVPNのネットワークを作ったり、
DBの通信にしようしたり、Heartbeat専用のネットワークを作ったり。

まぁ、いろんな設計が無停止で柔軟に出来るようになっています。

ネットワーク追加も従量課金で20円/時間で課金され、1か月1万円が課金上限になるシステムです。

参考： http://blog.idcf.jp/entry/etc/add_network/

で、今回は既存の環境から移設というところで構築したのですが、

色々な制限があり再設計する事になりました。

結論から言うと、追加ネットワークを使った設計をする時は、

実際に追加ネットワークをしてから設計するか、IPを柔軟に変更できる設計にしておくと良いです。

例えばDBと接続する際にIP指定で許可している場合、許可設定の変更をしたり、

そもそもDBのIPが変更しなければならない可能性があります。

同じハマり方をしないようにご注意というところで。

１．システム予約IPがある

後方20個のIPはシステム予約として使用出来ないIPになっています。

例えば、デフォルトで以下NWが指定されます。（もちろん変更可能）

192.168.0.0/21

上記のうち、192.168.7.235～254はシステムで予約して使用不可能になっています。

従って、後方20IPを使用したIP設計は見直しになります。

２．CIDRが/24～/21のみ

CIDRは/24～/21でしか使用できません。/25、/26のNWは作れません。

従って、/24よりも分割されたNWは設計見直しになります。

３．仮想ルーターにIPが自動で採番される

仮想ルーターにIPが自動で採番されます。これはシステム予約IPに含まれていません。

例えば、192.168.0.0/21のNWで構築した場合、どこに採番されるか解りません。

基本的には192.168.0.1が使用されるようですが、2や3が採番される可能性もあります。

仮想ルーターのIPは使用出来ないので、こちらも被った場合は設計見直しになります。

ご察しの通り、３に見事にはまりまして。

移設前は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であればさほど困らないかもしれませんが、、

参考 ： https://www.faq.idcf.jp/app/answers/detail/a_id/569/~/%E8%BF%BD%E5%8A%A0nic%E3%81%AE%E8%A8%AD%E5%AE%9A%E4%BE%8B%EF%BC%88centos7%E7%B3%BB%E3%81%AE%E5%A0%B4%E5%90%88%EF%BC%89

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に戻ります。

あまり使う機会は無いと思いますが。。

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

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

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

初級～中級、上級、テスト対策、いろいろとやります。

非エンジニア向けのクラウド勉強会などもやったりします。

ベンダーフリーで使うクラウドは問わないので、こんな勉強会やってよ！など、

ご依頼はtaka3110までご連絡頂ければ打ち合わせ/企画から一緒にやります。

さて、宣伝はこの辺にして。。

クラウド系の勉強会、特にハンズオンの勉強会をやるときに注意するポイントが結構あります。

今回、実際にハマるポイントを書こうと思います。

①　上限の確認

　複数人でやる場合、サーバーの上限やIPの上限等、

クラウドが定める上限値に達していないか確認をします。

上限以上を使用するならば、上限の緩和申請をサポートにしましょう。

殆どのクラウドで上限の緩和が可能です。

遅くても3営業日前には申請をするようにしましょう。

②　同じアカウント内で同時実行時のデフォルトパラメーター確認

　同じ資料を見ながら行った場合やデフォルトの値を使用する場合に、

値がすべて同じになってしまいエラーが続発する可能性があります。

特に同じアカウントでやる場合（AWSでIAM使用する場合も含む）は、

ユーザー名を追加する等、ユニークな値を入力してもらうようにしましょう。

例：AWSのサーバー起動時のセキュリティグループ等

③　リージョンの確認

　これもハンズオンをやる時にたびたび出る問題です。

多くのクラウドはリージョンの変更を行っても殆ど画面上に変化はありません。

リージョンを指定して、ログインした際に確認するように促します。

④　OS選択時のマイナーバージョンの確認

　OSによってはマイナーバージョンが違うだけでログイン方法が変わるものがあります。

（管理者ログインが禁止されているものなど）

テンプレートやAMI等を選んでもらう際にはID等で解るようにしておきます。

⑤　削除漏れの確認

　削除したと思ってDiskが残っていたり、スナップショットが残っていたりする事があります。

勉強会が終わったら、早めにリソース状況の確認を行って削除するようにしましょう。

⑥　サービスとアカウントを分ける

　これが一番恐ろしいんです！

社内の場合、同じアカウント内にユーザーを作成して多人数で実施するケースが多いと思います。

サービス提供をしているサーバーがある場合は間違えて停止や削除等の誤操作をする可能性があります。

結構触ってもらいたい場合、管理者に近い権限を付与する事になります。

教える側も緊張するので、なるべくサービスアカウントではなく、別途アカウントを取得するようにしましょう！

いたしかたない場合はリージョンを変更する等で容易に触れられない環境を作りましょう。

クラウドは便利なんですけど、便利だから簡単に出来るのではなく、

最低限の準備は必要という事ですね。

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

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
----

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

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

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

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

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

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

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

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

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

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

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

なんでブログって書けないんですかね。

これ書こう、あれ書こう、って思って休日を迎えるんですけど、

結果的に家族サービスや競馬やってるんですよね。

ITへの愛が足りないのか。愛が。

という訳で、環境から作ろうという事でブログを書くきっかけを作りました。

IDCFクラウドで新しくアンバサダープログラムが始まりました。

その名も「MORIO Dojo」（モリオ道場）

http://www.idcf.jp/cloud/dojo/

IDCFクラウドの使いっぷりやコミュニティでの活躍っぷりによって、

段位認定してくれるというシステム。

このプログラムに参加すると、クローズドのコミュニティに参加して、

IDCFクラウドに長けたいろんな方々と会話が出来たり、

限定イベントに招待してもらえたり、プレゼントもらったり出来るそうです。

段位自体は空手みたいな感じで帯色によって認定が分かれてます。

段位認定の条件をクリアすれば次の段位へ！という形で、

最高段位のMORI帯を目指す。という感じのようです。

ゲーミフィケーション的な感じで面白いですね。

私もコミュニティを運営している端くれとして青帯で認定依頼をしたところ、

認定してもらえた次第です。

MORI帯までの道のりとして、一番の山場は3か月間、1か月に1度はIDCFクラウドの記事を書く。

基本、このブログはIDCFクラウドネタが多いのですが、連続性が無い、というか、

ブログを続けて書けない人なので、これをモチベーションにしてブログを続けてみようと。

そういう次第であります。

さて、私のクリア状況ですが、

白帯：

◎PCにMORIOステッカーを貼ってる

◎個人で発信する媒体を持っている

青帯：[いまここ]

◎ユーザー会への参加

○クローズドコミュニティでの積極的な発言

茶帯：

×IDCFクラウドのバナーを貼っている

△IDCFクラウド関連の記事を投稿（1か月に1回程度）

黒帯：

×IDCFクラウド関連の記事を3か月連続で投稿

◎お客様の声への協力

MORI帯：

◎ユーザー会を運営

×コミュニティテンプレートを公開

という訳で、茶帯は直ぐいけそうですが、黒帯は3か月後になりそう。

飛び級出来るなら3か月後にはMORI帯になれるんじゃないかと。

白帯については割と直ぐに認定されそうです。

青帯ですが、ユーザー会への参加があります。

東京では6月28日（火）にユーザー会を予定してますので、

こちらもチェキっといてもらえれば来月には青帯になれると。

ユーザーコミュニティ

東京：https://idcfcloudug.doorkeeper.jp/

大阪：https://idcfugosaka.doorkeeper.jp/

つくば：https://idcfugtkb.doorkeeper.jp/

というか、ユーザーコミュニティを作ってしまえばMORI帯の条件をクリア出来ます。

初めての運営でもmeetup運営メンバーに優しくサポートしてもらえます。

作りたいけどどうすんの？とか、やりたいから手伝って！

という方は以下の問い合わせから連絡くれればお手伝いします。

https://idcfcloudug.doorkeeper.jp/

MORIO道場で検索すると奈良のよくわからん公共施設がヒットするので、

検索するときはMORIO Dojoで検索しましょう。

もしくは以下URLからどうぞ。

http://www.idcf.jp/cloud/dojo/

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

メール配信で送信元IPを変更しながら負荷分散をする

最近検証したネタの備忘録です。

メール配信での悩みはキャリアのブロッキングです。
複数IPを持ってタイムコントロールをしながら配信管理をする事で、
キャリアの閾値以内で収めて配信する必要があります。

これが想像以上に面倒で、しかもspam認定されると解除もとても面倒なので、
SendGrid等の安価でAPIが使えるメール配信サービスをお勧めしています。

今回はどうしても内製化しなければならず、どうにか出来ないか？という話があったので、
どうにか作れないもんかと試行錯誤してやってみました。

先日クーポンを頂いた「さくらのクラウド」で試してみます。
メールの大量配信についてはどのクラウドでも推奨事項ではないので、あくまでもテストという事で。
一応、約款を見てもspamじゃなければ問題無さそうだったのでテスト環境に採用しました。

さくらのクラウドの良いところは、とにかく柔軟に何でも作れるというところだと思います。
価格設定～コントロールパネルまで全てオリジナリティのある内容なので、
どこか独立系のイメージがあります。IDCFクラウド同様に尖がってるなぁというイメージです。

今回はIPが複数必要だったので/28で払い出されるRouterを帯域幅100Mで契約しました。
/28ですが使用出来るIPの数は11個です。
サーバはCentOS release 6.7 (Final)を1GB/1仮想コアを契約しました。

今回はpostfixを使用して、間にHAproxyを挟んで負荷分散させます。
問題は送信元IPを変更するところなのですが、こちらはpostmultiを使って解消しました。

手順は以下です。
１．サーバにIPを割り当てる
２．必要なミドルウェアをインストールする
３．postmultiでpostfixインスタンスを複数構成にする
４．リレーの設定をする

以下のような構成を作ります。
事前にDNS(mxやtxtレコード)は設定しておきます。

まずはサーバにIPを割り当てますが、今回はセカンダリIPで手っ取り早く済ませます。
-----------------------
# vi /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE=eth0:1
NETMASK=255.255.255.240
IPADDR=[使用範囲内のIPアドレス]
# ifup eth0:1
-----------------------
同様にeth0:2、eth0:3・・・と作成していきます。

次に今回使用するミドルウェアをインストールします。
postfixはデフォルトでインストールされているものを使用するので、
必要なのはhaproxyです。
（接続確認用にtelnetを入れておくと便利です。）
-----------------------
# yum install haproxy
# yum install telnet
-----------------------


HAProxyの設定をします。
-----------------------
#vi /etc/haproxy/haproxy.cfg
listen smtp
  bind 127.0.0.1:25
  mode tcp
  balance roundrobin
  server mail2 インスタンス2のIPアドレス:25 check
  server mail3 インスタンス3のIPアドレス:25 check
  server mail4 インスタンス4のIPアドレス:25 check
  server mail5 インスタンス5のIPアドレス:25 check

listen smtp2
  bind HAProxyに設定するIP:25
  mode tcp
  balance roundrobin
  server mail2 インスタンス2のIPアドレス:25 check
  server mail3 インスタンス3のIPアドレス:25 check
  server mail4 インスタンス4のIPアドレス:25 check
  server mail5 インスタンス5のIPアドレス:25 check
-----------------------


次にpostmultiを使用した環境に変更をします。
マスターのpostfixは止めておきます。
# /etc/init.d/postfix stop

メールの受付/キューイング用にインスタンスを１つ。
そして配信用に複数のインスタンスを作ります。

postmultiでの複数インスタンス作成（例はインスタンス名postfix-mail1）
-----------------------
postmultiの構成の初期化
# postmulti -e init

postmulti構成でのインスタンス作成
# postmulti -I postfix-mail1 -G postfix -e create

作成したインスタンスの有効化
# postmulti -i postfix-mail1 -e enable

インスタンスの起動/停止
# postmulti -i postfix-mail1 -p start
# postmulti -i postfix-mail1 -p stop
-----------------------

postmultiのインスタンスでinet_interfacesにIPを指定します。
これが配信元IPとなります。
mydestinationやrelayhostの設定を行います。
postmultiのキューイング用インスタンスのコンフィグ変更点
-----------------------
inet_interfaces = 設定するIPアドレス
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, メールのドメイン
relayhost = [127.0.0.1]:25
relayhost = [HAproxyの設定アドレス]:25
default_destination_concurrency_limit = 1
default_destination_recipient_limit = 1
master_service_disable =
allow_mail_to_commands = alias,forward,include
-----------------------
配信用インスタンスは上記からrelayhostの設定を外します。

これで前記の構成が完了しました。
複数アドレスを記載したaliasを用意して、そのアドレスに外部から送信すると、
配信元IPを変更して送信される事がわかるかと思います。

まだこの状態ではセキュリティの担保等の複数問題点が残っていますが、
配信元IPを変えて送信することができました。

ここまでやって思うのは、やはりメールサーバは外部サービスが便利ということ。
メールサーバの運用は色々と面倒が多いので、内製化が必要なケースでも、
なんとか外部サービスに委託する形にもっていった方が、全員が幸せになるんじゃないかなー。
と思う次第です。

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

IDCFクラウドの新旧light.S2を比較してみる

IDCFクラウドが10月にエントリー向けのlight.S2の料金を半額に価格改定しました。
これだけでも衝撃的だったのですが、CPUのクロックアップもしており、
実質的には半額で性能倍という、これまた面白い価格改定でした。

年末でサーバー整理をしていたところ・・・なんと、旧light.S2が未だ稼働しているではないですか！
ということで、旧light.S2のサーバーを新light.S2に変更して、
今更ながら新旧でほんまに性能倍になっとるんかいな？という検証をしてみたいと思います。
ちなみに新たにlight.S2を契約すると、全て新スペックとなりますので、あしからず。

まずはCPUを見てみましょう。
model name      : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
新旧light.S2ともにCPUのモデルは変わっていないようです。
どうもクロックの制限に変化があるだけのようなので、
いつも通りWordpressに負荷をかけるやり方で確認してみます。

例のごとくyumでインストールしたLAMP環境にWordpressのver3.0をインストールします。

まずは10アクセス/10クライアントでのチェック。

#ab -n 10 -c 10 http://localhost/wordpress/

旧

Requests per second:    6.18 [#/sec] (mean)

Requests per second:    5.56 [#/sec] (mean)

Requests per second:    5.16 [#/sec] (mean)

新

Requests per second:    6.50 [#/sec] (mean)

Requests per second:    5.64 [#/sec] (mean)

Requests per second:    6.21 [#/sec] (mean)

変わりませんね。誤差です。

クロック制限については、ある程度負荷をかけないとVM上で認識されている、

仮想CPUの性能速度で値が返ってきてしまうので、ここまでは想定内です。

なので、そんなに負荷がない環境でMemoryもそんなに使わない。というのであれば、

light.S1とlight.S2は変わりません。

次に100アクセス/100クライアントでチェック。

#ab -n 100 -c 100 http://localhost/wordpress/

旧

Requests per second:    1.83 [#/sec] (mean)

Requests per second:    1.86 [#/sec] (mean)

Requests per second:    1.89 [#/sec] (mean)

新

Requests per second:    4.33 [#/sec] (mean)

Requests per second:    3.74 [#/sec] (mean)

Requests per second:    4.41 [#/sec] (mean)

見事に性能がアップしています。

旧の方はクロック制限に見事に引っかかって伸び悩んでいるのに対して、

制限が倍になった分が新しい方は伸びています。

価格が変わった分、変更しないと損なのは間違いないですが、

性能面からみても、変更する価値は十分にあることが解りました。

ハードウェアの認識も変わらず、あくまでクロックアップしただけのようなので、

何か紐づいたアプリケーションを使っていても、そこまで気を遣う必要はなさそうです。

ちなみに月の途中で性能変更する際には、変更後は新たに課金が始まるので、

上限（月額）まで達している場合は、新たに月が変わってからの方が良いかもしれません。

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