検索:

CloudStackの導入 – 動作確認・移行編

前回のノードサーバー編ではLinux上にCloudStackのエージェントソフトをインストールし

CloudStackにノードサーバーを追加しました。さらに仮想サーバーを停止することなく

移動することが出来るライブマイグレーションについて書きました。
今回は最終回…動作確認・移行についてです。

CloudStackが完成したのでいよいよ仮想サーバーを作成します。
と…その前にVLANを作成します。例えば、192.168.0.xxx/24や172.16.0.xxx/24というVLANを

用途毎に作成します。

仮想サーバーをゼロから作成するためにLinuxやWindowsのイメージファイル(iso)をCloudStackに

アップロードします。それから仮想サーバーに作成時にisoファイルをマウントするようにして
OSをインストールします。

仮想サーバーが出来れば、サーバーを停止してCPUやメモリを増強し正常に稼働し増強出来ているか

確認します。さらに仮想サーバーを稼働させたまま他のノードサーバーへライブマイグレーションが

正常に機能するかも確認します。

仮想サーバーの動作確認が出来れば…次は仮想サーバーにいつもインストールするツールなど

インストールして標準となる仮想サーバーを作成します。それをCloudStackへテンプレートとして
登録します。次回よりテンプレートから仮想サーバーを作成することでOSやツールを

インストールする時間を大幅にが短縮出来ます。

次に既に仮想している旧CloudStack環境からの移行です。今回弊社では新旧はまったく別の

環境として構築しましたので仮想サーバーを稼働しながらのライブマイグレーションは出来ません。
まずは旧CloudStack環境で稼働している仮想サーバーを停止してOSやデーターを移行作業用のPCに

ダウンロードします。それを新しいCloudStack環境にテンプレートやデーターとしてアップロードし…

テンプレートから仮想サーバーを起動することで移行出来ます。ファイルのサイズが数十GB以上ありますので
移行には稼働しているシステムへの影響を最小限にするために数週間から数ヶ月かかります。

最後はZabbixやNagiosなどの監視ツールに設定を追加して作業は無事完了です。

■ あとがき

今回、新しいCloudStack環境への移行作業は、新バージョンのCloudStackを
検証したりサーバーをリプレースするなどの作業があり半年以上かかりました。
ハードウェアの交換などは現地のスタッフが作業しましたので私は一度もデーターセンターへは

行っておりません。すべてリモートワークで完結しました。

CloudStackの導入 – ノードサーバー編

前回のクラウドコントローラー編ではLinux上に管理サーバーとデータベースサーバーをインストールし

ブラウザから管理画面にアクセスしCloudStackでインフラを構築出来る事について書きました。
今回はノードサーバーの導入についてです。

ノードサーバーとはCloudStackで作成する仮想サーバー、仮想ルーター、仮想スィッチに

CPUとメモリなどのリソースを提供するサーバーです。

ノードサーバーはハイパーバイザー(仮想サーバーを動かすソフトウェア)です。
Hyper-V、KVM、VMware、XenServerなどが利用出来ます。弊社ではKVMを使用しております。

KVM(Kernel-based Virtual Machine)とはその名のとおりLinuxカーネルをハイパーバイザとして

機能させるための仮想化モジュールでLinuxに組み込まれたオープンソースの仮想化テクノロジーです。

ようするにKVM を使用すると、Linux がハイパーバイザーになります。

ノードサーバーの構築は簡単です。LinuxをインストールしてCloudStackのエージェントソフトを

インストールする…後はCloudStackの管理画面でノードサーバーを追加するだけです。

CloudStackが非常に便利なのは…CPUやメモリなどが不足したら新しい物理サーバーを購入し

ノードサーバーとして設定しCloudStackの管理画面で追加すれば増強出来ます。
さらに…古くなったノードサーバーから新しく追加したノードサーバーへ仮想サーバーを

停止することなく移動することが出来ます。これはライブマイグレーションという機能です。

これだけでもCloudStackを導入するメリットがあります。

■ あとがき

初めてライブマイグレーションした時はちょと感動しました。物理サーバーではありえない機能です。

CloudStackの導入 – クラウドコントローラー編

前回のストレージ編ではNFSサーバーの導入について書きました。
今回はクラウドコントローラーの導入についてです。

ネットワーク構築やストレージサーバー導入まではCloudStackに特化せず一般的な話しでしたが、

今回からはCloudStackのソフトウェア導入の話しになります。

まずはLinuxをインストールするハードウェアですが、以前は物理サーバーにインストールしておりましたが、

今はハイパーバイザー(仮想サーバー動かすソフトウェア)上にインストールしてあります。
CloudStackで使用しているハイパーバイザーとは別のソフトウェアを使用しております。

CloudStack上で稼働している仮想サーバーのバックアップサーバーもこちらで稼働させていますので
最悪CloudStackがすべて停止してもサービスは継続出来るような構成にしております。

クラウドコントローラーとはストレージサーバーやハイパーバイザーをリモートから操作するものです。

仮想サーバーに割り当てるストレージを作成しCPUやメモリを割り振って仮想サーバーを作成する機能や
仮想ルーターや仮想スィッチを作成しVLANを作成するなどです。

クラウドコントローラーに使用するOSはLinuxです。そこにCloudStackの管理サーバーと設定情報を

格納するデーターベースをインストールすることでCloudStackのクラウドコントローラーが作成出来ます。
どちらもNFSサーバーと同様にサーバー2台を1セットとしてデーターを常時複製し冗長化しております。

クラウドコントローラーが作成出来ればいよいよCloudStackの設定です。

<ゾーン>
データーセンターのようなものです。地理的に離れたデーターセンターを複数利用しているのであれば
それぞれのゾーンを作成することになります。

<ポッド>
データーセンターのラックというイメージです。複数のラックが追加出来ます。

<クラスター>
ポッドに追加するものです。クラスターには次回の号で書くCPUやメモリなど提供するノードサーバーを

追加します。

<プライマスストレージ>
OSやデーターを格納する場所です。

<セカンダリストレージ>
ISOイメージファイルやOSのテンプレートを格納する場所です。

他にも初期設定として物理ネットワーク、共用トラフィック
ゲストトラフィックなどを設定します。

CloudStackの管理画面は多言語対応されております。機能もわかりやすくマニュアルも整っておりますので
やる気と根気があれば時間がかかりますが習得出来ます。

■ あとがき

ブラウザ上でインフラが構築出来る…パブリッククラウドでは当然ですが、
それを自社のインフラでも構築出来るCloudStack最高です。

CloudStackの導入 – ストレージ編

前回のネットワーク編ではインターネット回線やVLANの設定などについて書きました。

今回はストレージの導入についてです。

ストレージと言っても規模により様々製品や技術があります。
CloudStackではNFS,iSCSIなど様々なファイル共有システムをサポートしておりますが、

弊社ではNFSを使用しております。

CloudStackで使用するストレージにはOS、データーなどすべての情報が格納されるので

これが停止すると仮想サーバーが全部停止してしまいパニックになること間違い無しです。

安定稼働と障害対策が非常に重要です。

NFSサーバーとしてはメーカー製のストレージ専用サーバーがあります。
規模にもよりますが、製品本体はもちろんサポートサービスも非常に高価であります。

特に障害発生の緊急事態時に自社で対応出来ないのは不安です。特に中国では不安です。

問題無い…で終わってしまっては非常に困ります。死活問題になります。

もちろん中国の代理店によってはサポートのレベルが非常に良い会社もあります。

日本だとメーカーのサポートは良いのですが、他社のサポート担当者のデーターセンター入館手続きで

申請した名前の一文字が身分証明書と違うとか…パーツの型番が1文字違うなどで再申請のループとなり
復旧まで時間がかかるという落とし穴があります。

弊社ではNFSサーバーとして…ハードウェアはメーカー製の汎用サーバーを使用しております。

もちろんRAID構成です。さらにサーバー2台を1セットとしてデーターを常時複製し冗長化しており

サーバーが1台故障しても停止時間は最小限になるように設計しております。
OSはLinuxでデーターを複製するソフトウェアはオープンソースを使用しておりますので

障害発生時は自社でほぼ対応可能です。ストレージサーバーが設定出来たら最後はディスク速度の計測です。
ハードウェアの導入時期やRAID構成によってスピードはかなり違います。

CloudStackの機能としてディスク容量の増加やデーターを別のストレージへ移動することが管理画面で

簡単に出来ます。これは非常に便利です。新しいストレージサーバーを導入した場合、仮想サーバーを

停止する必要はありますが、管理画面で数クリックすることで移動出来ます。

■ あとがき

Linuxとオープンソースのソフトウェアで冗長化されたNFSサーバーを10年以上使用しておりますが、

非常に安定しております。何と言っても…精神的に安定です。

CloudStackの導入 – ネットワーク編

前回の準備編ではデータセンターの選定について書きました。今回はネットワークについてです。

インターネット回線…帯域やグローバルIPアドレスの個数を決めます。
日本ですと希望どおりのサービスが安定して受けられますが、中国ではそう簡単にはいきません。

特に海外との通信に問題のある回線があります。導入後も国による規制などに対応しなければなりません。
事前連絡がなく突然特定のIPアドレスの特定のポートが閉じられることもあります…

これを書くときりがないので過去の記事をご参照ください。

UTM(統合脅威管理)…ルーティングやファイアウォール、VPNなどに弊社では米国メーカーの製品を

導入しております。日本と中国で安定して購入出来る製品を選んでおります。

Switch(スィッチングハブ)も同じく米国メーカーです。

インターネット回線が準備出来たら…ラックにUTMとSwitchをマウントしLANケーブルを配線をします。

その前にインターネット回線が正常に通信出来るか確認する必要があります。

以前、中国で経験したのはLANケーブルを接続した途端に物凄い攻撃を受けたり…非常に通信が
不安定だったり色々問題を経験しました。

通信の正常が確認出来たらCloudStack用にSwitchのVLANを設定します。

管理・監視、ストレージ、サービス用にそれぞれVLANを設定します。
後で変更するのは大変なのでここでの設計・設定が重要です。

これでネットワーク構築が終了と思われますが、一番重要な作業があります。
ネットワークが安定するか確認です。ラック内のLANとラック外のネットワークに監視サーバーを

設置し1週間程度…遅延、パケットロス、通信速度等の統計を取ります。
ある曜日のある時間帯に通信が異常に増えたり海外からの通信経路が
おかしいなどあるかもしれません。監視サーバーで統計を取得しているとトラブル対応の

手助けになるかと思います。中国でトラブル時に電話で問い合わせても…「問題無い」で

終了してしまいます。その時に遅延やパケットロスの統計情報があれば資料を作成し送付することで

もしかして対応してくれるかもしれません。

■ あとがき

メールサーバー構築するのであればDNSの逆引きの対応も必要です。
そして際も重要なのが中国で必要な手続きであるICPの申請です。これを申請しないと…

CloudStackの導入 – 準備編

弊社ではデーターセンターにあるプライベートクラウドにオープンソースの

クラウド基盤ソフトウェアであるCloudStack(クラウドスタック)を利用しております。
AWS,Azure,GoogleCloudなどにある…ブラウザ上で数クリックするとサーバーが

出来るというサービスを自社のインフラで実現出来るものです。

弊社では日本と中国の複数箇所でラックを借りており7年程前からCloudStackが

稼働しておりますが、クラウド基盤が動いているOSのサポート期限が切れるので
今回はOSの再インストール作業になります。ついでにCloudStackも新しいバージョンへ移行します。

今回より何も無い状況からCloudStackを導入する場合の手順について数回に分けて書いていきます。

まずはデーターセンターの選定です。日本ですとどこを選んでも大きな失敗はしないと思いますが、

問題は中国側です。立派な建屋から…ここに本当にデーターセンターがあるの？…というような

外観の建屋など色々あります。外観は妥協するにしても電源とネットワークが安定していることが

最重要事項です。できればセキュリティーがちゃんとしていれば安心です。

電源設備…UPSや発電設備など素人が見てもわかりません。

ネットワークも同じく帯域などスペックだけではわかりません。
結局、実際にシステムを導入して数ヶ月～1年ほどしないと状況がわかりません。

トラブルは100%発生するのでどこまで障害の影響を抑えるかになります。

日々システムを運用していくにあたり中国では技術的なことはもちろんですが、
通信会社やデータセンター側との交渉が非常に重要です。
会社設立から20年…色々とありえないトラブルを経験しました。
詳細については過去の記事をご参照ください。

■ あとがき

システムを導入する場合、まずはパブリッククラウドを選ぶのが一般的になった今、自社で

ハードウェアを保有する必要があるのかと思われるかもしれませんが、

中国では自社でコントロール出来るのであればそれに越したことはありません。

今まで…えらい目にあってきた経験者談です。

DNSサーバー

DNSサーバーには用途により主に下記の2タイプがあると思います。

・権威DNSサーバー：自社ドメインの運用
・キャッシュDNSサーバー：サーバーやクライアントに設定

今回はキャッシュDNSサーバーの話しです。
例えば、www.example.comというホームページを開く時に
キャッシュDNSサーバーが正常に稼働していないとホームページが
開けないなどのエラーが発生します。

弊社ではDNSサーバーの稼働状況をツールで監視しております。
CPU,メモリなどOSの監視はもちろんDNSサーバーの問い合わせに対する
成功とエラーの数も監視しております。ここ最近ですがエラーの数が
増えてきました。例のスゴイ壁では色々な方法で規制しておりますが、
DNSを利用した規制の方法も有るようです。今年は政治的に色々あると
思いますのでシステムをバージョンアップしたのでしょうか？

中国でISPのDNSサーバーをPCに設定してあるとブラウザを開いた時に
意図しないホームページが開くことがあります。一度これが開くと
次回も開くようになり嫌な思いをしたことがあるかと思います。

汚染されたDNSサーバーを利用したくないので弊社では昔から
すべてのDNSサーバーを自社で運用しております。
大企業は別として一般的にファイルサーバーは有っても
キャッシュDNSサーバーを自社で運用されている企業は少ないと思います。
多くの企業ではISPのDNSサーバーを利用されているのではと思います。

今回、キャッシュDNSサーバーを増設しロードバランサーも追加しました。
さらにネットワークやDNSの構成を中国向けに最適化してみました。
DNSサーバーの応答速度が速いとホームページを開くのも若干速いように
感じます。弊社データセンターとインターネットVPNで接続して頂くか
お客様のインターネット回線が固定グローバルIPであれば
弊社のキャッシュDNSサーバーをご利用頂けますので
お困りでしたらご相談ください。

■ あとがき

最近、東京は暑いです。ということでデータセンターへ涼みに行ってきます。

ソフトウェアルーターでレイヤー２接続

オフィスにあるサーバーをデーターセンターへ移設する場合、
オフィスとデーターセンターをVPNなどで接続すると思います。
その際、データーセンターにはオフィスと異なるIPアドレスを使用すると
思います。でも、どうしても同じIPアドレスを使用したい場合が有ります。
その場合「専用線」で接続すれば良いのですが、「専用線」を
引くには時間がかかります。今の時代、サーバーはクラウドを使用し
数分で作成出来るのにネットワークの接続に時間がかかってしまっては
困ります。そこで「ソフトウェアルーター」の登場です。

ルーターと聞くと専用のハードウェアを思い浮かべると思いますが、
サーバーまたはPCに「ソフトウェアルーター」をインストールして
同じことが出来ます。普通の使い方であればこれで十分かと思います。
「ソフトウェアルーター」といってもルーティングはもちろん
ファイアウォールやVPNなど多機能です。

さらに「ソフトウェアルーター」でオフィスとデーターセンターを
「レイヤー２」で接続することが出来ます。
「レイヤー２」…ようするにオフィスとデーターセンターが
同じLANということです。同じIPアドレスが使用出来ます。

「ソフトウェアルーター」はLinuxがベースとなっていますので
Linuxが稼働する物理サーバーまたはPCで稼働します。
さらに仮想サーバー上でも稼働します。ということは…クラウド上に
短時間で「ソフトウェアルーター」を導入出来るということです。

実際、私は一度もデーターセンターに出向くことなく数時間で
２つのデーターセンター間をレイヤー２で接続出来ました。
昔ではありえないことですね。

■ あとがき

拠点間やオフィスとデーターセンターを「レイヤー２」で接続されたい場合は
ご相談ください。ご用意いただくのは「サーバーまたはPC」と
「インターネット回線(グローバルIP１個)」です。

ストレージサーバー

ストレージ…当たり前ですがとても重要です。
以前は物理サーバーに搭載されているハードディスクにOSやデータを
格納しておりましたが、プライベートクラウドとなると
仮想サーバーにCPUやメモリを提供する「ノードサーバー」と
ハードディスクを提供する「ストレージサーバー」というように
分離された構成となります。

「ストレージサーバー」にすべてのOSやデータが格納されます。
もし「ストレージサーバー」が停止すると…想像したくありませんが、
仮想サーバーがすべて停止します。

数ヶ月前、弊社の「ストレージサーバー」の1台で障害が発生しました。
二重化してあるのでサービスが停止することはありませんでしたが、
エラーメッセージを見た瞬間気絶しそうになりました。

一度障害が発生したサーバーを使い続けるのは怖いので
これを期にストレージサーバーをリプレースすることにしました。
ストレージ専用のサーバー製品を導入するという方法がありますが、
高価過ぎて費用対効果を考えると導入出来ません。
しかもそのような製品はブラックボックスとなっている部分がありますので
不具合が発生した場合、自社で復旧出来るか不安です。
中国だとメーカーのサポートに頼るのはキケンです。(経験者談)

そこで普通のサーバーに弊社が得意とするLinuxとオープンソース
ソフトウェアでストレージサーバーを構築します。
サーバーを二重化するなど色々と対策をしており5年以上安定稼働した
実績のある構成です。不具合が発生してもノウハウがありますので安心です。

早速サーバーを代理店へ注文することにしました。
とにかく急いでおりました。見積をもらい発注したところ
「RAIDカードの在庫がありません」と言うではありませんか…
さらに「RAIDカード無くても大丈夫」とまで言っております。
さらにさらに「RAIDカードの納期は2週間」と言っております。

とりあえずRAIDカード以外を持って来るように依頼し
OSをインストールし「ソフトウェアRAID」で
構成してみたところ…遅い。当たり前です。

また例のごとく私は中国人スタッフに「RAIDカードが無いとイヤだ」と
ワガママを言います。すると…中国人スタッフが代理店と交渉します。
その結果…スタッフ曰く「RAIDカード夕方に届きます」
ん～何故有るのでしょうか？深く考えるのはやめておきましょう。

夕方にRAIDカードが届きましたので早速使ってみました。
速度がなんと20倍です。思わずPCの画面を二度見してしまいました。
その後、無事にストレージサーバーの交換も完了し安定稼働しております。

■ あとがき

「無い」けど「有る」…不思議ですね。
たぶん代理店の担当者が必死で探してくれたのかもしれません。

ロードバランサー

今回は負荷分散装置…ロードバランサーについてです。
弊社では基本的にサーバーはクラスタリング構成とし二重化しております。
クラスタリングだと障害発生時、瞬時にバックアップ側に切り替わり
ますので安心ではありますが、平常時はバックアップ側が使われないという
欠点があります。アクセス数が増えサーバーを増強したい場合、CPU交換や
メモリを増設する必要があります。今ではプライベートクラウドですので
ブラウザの管理画面からメモリを増やすことが出来ますが効率的ではありません。

そこでロードバランサーです。ただし物理ロードバランサーだと
数百万円します。多機能・高性能である必要はないのでそこまでコストを
かけることが出来ません。ということで前から気になっていた
Linuxでロードバランサーを構築してみることにしてみました。

かなりいいです。機能は申し分有りません。
実際に運用するとなるとロードバランサーの二重化やアクセス数の増加にも
対応しなければいけません。二重化ですが、ロードバランサーを2台稼働させ
クラスタリングにすることが出来ました。切り替わりも1～2秒程度です。
次にアクセス数増加への対応です。下記のような構成が考えられます。
ただしこの構成だとロードバランサーを必ず通りますのでここが
ボトルネックになりそうです。

[クライアント]<->[ロードバランサー]<->[サーバー]

そこでDSR(Direct Server Return)です。
これは下記のようにサーバーからクライアントへの通信をロードバランサーを
通さずに直接クライアントへ返すという構成です。
これだとロードバランサーにあまり負荷はかかりませんので
アクセス数が増加してもサーバーを増やすだけで対応出来ます。

[クライアント]->[ロードバランサー]->[サーバー]->[クライアント]

しかもプライベートクラウドにテンプレートとして登録してあるため
数分で起動し設定を含め30分程度でロードバランサーが稼働します。

https://wwwevolutionnetworks.net/service/cloud.html

■ あとがき

上海でLinux関連の案件がございましたらご相談ください。
私が飛んで行きます。