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等、旧ゾーンで性能が足りなくなってきたと感じたら、
ゾーン移設を検討するのも１つの手です。
複数台構成であれば、GSLB機能もあるのでサービス停止を回避しながらゾーン移設も可能です。

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

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

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

どうもtaka3110ことどんです。

今回は待った無しになっているATS対応の話です。

そもそもATS対応って何じゃい？という方は、こちらをご参照下さい。

「ATS + IOSの検索結果」

簡単に言うと、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で入れた同じモジュールを使えるのではないか説が沸きあがり、

実際にやってみたら使えたのでご紹介します。

（実際にやっても自己責任でお願いしますね・・・）

１．作業ディレクトリ作成

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

mkdir /root/src

cd /root/src

２．ソースゲット

最新版のソースをゲットします。

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

３．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 ..

４．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です。

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

５．初期コンフィグのバックアップ

戻せるようにしておきましょう。

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

６．既存モジュールのcopy

yumで入れたモジュールをコピーします。

#パスは64bitの場合です。

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

７．既存コンフィグのコピー

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

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/

８．設定ファイル類のディレクトリ構成設定

運用性を考えて同じディレクトリ構成にしておきましょう。

mv /etc/httpd /etc/httpd.org

ln -s /usr/local/httpd-2.2.31 /etc/httpd

９．起動ファイルの変更

戻せるようにしておくのと、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

１０．mod_sslのモジュールのみコピー

mod_sslは今回コンパイルしたものを使います。

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

１１．logやrunフォルダの設定

logフォルダは引き継ぐようにしておきます。

mkdir /etc/httpd/run

mv /etc/httpd/logs /etc/httpd/logs.org

ln -s /var/log/httpd /etc/httpd/logs

１２．アップデートした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

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台でやってしまいましょうと。

そうすると、やり方としてはざっと考えて２つあって、
・ セカンダリ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により処理する。
というのはあり得る話なんですが、少し気持ち悪いなぁ。と思うのは私だけかしら。。

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

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

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://～に書き換えれば読み込めます）

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