Cloud n にオールインワンサーバを立てる 1
実際こんなことをしている場合ではないが、家庭の状況が一段落ついた上に思い立ったので書いてみた。
現在運用しているサーバは NTT Communications の Cloud n を利用している。
その名が表すように、今はやりのクラウドサービスだ。クラウドという概念を一言で表すなら、実体のないもの。雲のような何か。
例えば、仮想的なインフラ基盤やサーバ群の提供すること (IaaS)。プラットフォーム (開発環境) だけを提供すること (PaaS)。特定のサービス (WEBメールなど) を提供すること (SaaS)。
私が使っているのは、上記で言えば IaaS の仮想サーバ (仮想マシン) に当たるだろうか。
仮想サーバの概念はそう難しくない。私のパソコンに仮想 PC ソフトをインストールして、ゲスト PC 用の設定を行う。ゲスト PC は私の PC に作成されたファイルを、仮想 PC ソフトがエミュレートして仮想的な PC に見立てたものだ。つまりゲスト PC が仮想マシンに当たる。上記のファイルを 2 つ作ればゲスト PC が 2 台、つまり仮想マシンも 2 台となる。
クラウドの場合、これがもう少し複雑になる。
まず複数の物理サーバ (Computing node) とそれを制御する管理サーバ (Management Server)。 Computing node で共有されるディスク領域 (Primary Storage) には仮想マシンのファイルが置かれ、さらに仮想サーバのバックアップなどが置かれる領域 (Secondary Storage) が用意される。そしてそれらをネットワーク的につなぐスイッチ。さらにインターネットとこれらインフラ環境を中継するファイアウォールやロードバランサも必要となるかもしれない。これらがクラウドのハードウェアだ。
さらに突っ込んだ話をするなら、いくつかの Computing node (ひとつの場合もある) と Primary Storage で Cluster という単位が構成される。クラスタはサーバを収納するラックの 1 列に例えられる。このクラスタ内で複数の仮想マシンが起動する。
さらにクラスタがいくつか集まって (ひとつの場合もある) Pod という単位が構成される。これはラックそのものに例えられる。
さらに複数のポッドと Secondary Storage が集まって Zone という単位が構成される。これは複数のラックを保守するデータセンターに例えられる。
お前何言ってるのか分かんねーよw
というわけで、何台もの物理サーバが並列起動しているから、それらの一つか二つが故障したって安全だという話がしたかった。
2011年の 3 月、自宅でのサーバ運営は自由度が高い代わりに災害に弱いと実感したため、 NTT Communications に Cloud n サービスが始まると即座に申し込んだ。
しかしそれが罠だ。
当時、Cloud n の仮想サーバはバグ満載のサービスだった。仮想マシンが仮想ネットワーク上に置かれていたのが一因だった。
このサービスで仮想マシンを作るとローカルの IP アドレス (10.100.101.102 みたいなアドレス) が提供される。当然インターネット上のグローバル IP アドレスとローカル IP を通信する経路情報を持った仮想ルータがあり、これが機能停止しまくっていた。
「1 週間に何回落ちてんねん!」って言うくらい、ボケナスな仕様だった。
仮想マシンを再起動することで直ることもあるのだが、直らないこともあって、その場合仮想ルータの再起動が必要になる。当初、これはサポセンにやってもらわなければならなかったが、稼働的に厳しかったのかユーザにもその権限を解放した。クソめんどくさい API での手順を踏むことによって。
何度このバグに迷惑を被ったか。これに関しての異論は認めない。被害を受けまくった私が保証するw
めんどくさいからクレームはつけなかったが、仮想マシンの OS が完全に機能停止状態に陥って、再起動することもできなくなり、別の仮想マシンを作らざるを得なくなった時に、 2 倍の月額料金を請求されたことは今でも根に持っているwww Linux のせいじゃなくてゼッタイ(w) 仮想マシンのバグ起因だ。
ちなみにこの頃の仮想サーバのサービスを VLAN プランと言う。
時は流れ、仮想サーバにグローバル IP を直接割り振った FLAT プランが誕生した。
見かけ上、直接インターネットに接続されている仮想サーバであるため、仮想ネットワーク環境起因の障害が発生する確率が減った。
何ヶ月か経過を見守っていたが、 FLAT の方が安定してる様子なので、重い腰を上げて VLAN から FLAT プランへ移行する決心がついた。
今では VLAN プランは申し込めず、 FLAT プランのみの受付になっているのも、 VLAN が障害上等なサービスである証拠だろう(毒w)
というわけで、 Cloud n の仮想サーバに Cent OS 6.5 をインストールしてオールインワンサーバを立てるまでの作業を備忘録として記録しておくことにする。
初心者の方にも分かりやすいように書いているつもりだけど、果たして需要はあるのかと我に帰ってみたりみなかったり。中級者以上の方には言われるまでもなく冗長なカンジになっております。
VLAN プランに別れを告げ、 FLAT プランの仮想サーバを追加する
基本的には次々に進んでいくだけだ。
1. FLAT プランで仮想サーバの作成開始
2. 仮想サーバ追加ボタンを押す
3. ゾーンを選択する
1 台構成ならどこでもいい。災害が起こらなさそうなゾーンを心眼で選ぶ。複数台構成ならサーバごとに別のゾーンを選ぶ。
4. Cent OS 6.5 を選ぶ
5. 最小プランにする
m1.small (1CPU/2GB) 以上にしなければオールインワンサーバとしては使い物にならないが、最初は絶対に t1.micro (1CPU/0.5GB) にすべき。サーバを構築してからプランアップするのがいい。設定が 1 ヶ月かかっても終わらないこともあるだろうし。
6. 追加ディスクはいらない
ハードに使っていくと不足することになると思うが、それは容量が少なくなった時に追加すればいい。とりあえずサーバを構築するまでは追加しない方が、財布にやさしくていいだろう。
7. セキュリティグループを選ぶ
ネットワークのセキュリティ名は一度決めると、後で変更不可という縛りがあるが、複数のネットワークセキュリティが必要なほど複雑な構成をさせるわけでもないし default のままで構わないだろう。
8. 仮想サーバに名前を付ける
9. パスワードが表示されるまで待つ
仮想サーバを作成するまでが長い。間違って別の画面に移行しようものなら、最後のパスワードが表示されずに、リセットの手順を踏む羽目になる。
ネットワーク設定
ネットワーク設定と言っても OS の eth0 設定のことではなくて、グローバル IP アドレスと仮想サーバ間にあるファイアウォールのポート許可設定のことだ。
この設定をしなければ全拒否になっている。従って、提供するサービスに応じてポートを解放していくことになる。
1. セキュリティグループの選択
2. Default のセキュリティグループ
何も設定していなければ default という名前のセキュリティグループが一つあるだけだ。これをクリックして、どんなポートを解放するのか、設定する。
3. ポート解放
とりあえず SSH/FTP/WEB/Mail/ICMP の許可を行う。
私的分類 | プロトコル | 開始ポート | 終了ポート | CIDR |
---|---|---|---|---|
SSH | TCP | 22 | 22 | 0.0.0.0/0 |
FTP | TCP | 20 | 21 | 0.0.0.0/0 |
FTP Passive | TCP | 60000 | 60030 | 0.0.0.0/0 |
WEB | TCP | 80 | 80 | 0.0.0.0/0 |
WEB SSL | TCP | 443 | 443 | 0.0.0.0/0 |
IMAPS | TCP | 993 | 993 | 0.0.0.0/0 |
SMTPS | TCP | 465 | 465 | 0.0.0.0/0 |
Submission | TCP | 587 | 587 | 0.0.0.0/0 |
SMTP | TCP | 25 | 25 | 0.0.0.0/0 |
Ping OUT | ICMP | 0 | 8 | 0.0.0.0/0 |
Ping IN | ICMP | 8 | 0 | 0.0.0.0/0 |
※ POP とか POPS とかが必要であれば適宜追加する。
SSH 接続環境
コンソール接続で設定することが非常にツライので、何を置いても早急に SSH 環境を構築する。
1. 仮想サーバ起動
2. root でログインする
ユーザは root。パスワードは仮想サーバを作る時に最後に表示されたやつだ。
3. グローバル IP アドレスの取得
まずは ifconfig でサーバの IP アドレスを調べる。ダッシュボードの [Penguin1] – [NIC] でも調べられるが、重すぎてイライラしているのでコマンドから調べている。
※ eth0 の inet addr: のところを見る
このサーバのグローバル IP アドレスは 153.149.34.61 のようだ。
4. root パスワードの変更
念のため、 root のパスワードを、最後に表示されたやつから自分なりのものに変更する。
# passwd root 思い思いのパスワードを入力する
5. SSH 設定
とにかくコンソールを卒業したいので、一刻も早く SSH 接続できる設定にする。
# vi /etc/ssh/sshd_config ・ root ログインを許可 (これは一時的な措置) PermitRootLogin yes ・ パスワードでのログインを許可 (これも一時的な措置) PasswordAuthentication yes
※ ファイルを保存する時に「:wq」と打たなければならないが、コロンは Japanese Keybord を選択して「SHIFT + け」のキーを押す必要がある。ああうざい……
root で SSH 接続するのはセキュリティ的に良くないのだが、最初だけだから大丈夫だ。万が一侵入されたとしても、仮想サーバを捨てて最初から作り直すだけだ。
# service sshd reload # exit
これで SSH 接続できる環境なったはずなので、あとは Teraterm なり Putty なり好みのアプリで SSH 接続する。
以上、 SSH 接続まで。