検索:

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年…色々とありえないトラブルを経験しました。
詳細については過去の記事をご参照ください。


■ あとがき

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

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

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

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

インフラ刷新

データーセンターにある弊社のサーバーは自社で構築・運用しております。
その昔…サービス毎に物理サーバーが有りましたが、
今は当然仮想化されております。その仮想サーバーをコントロールする
クラウドコントローラーも有ります。

物理サーバーをプライベートクラウドへ移行してから10年以上経過して
おりますのでインフラを刷新することにしました。
今さらパブリッククラウドではなくプライベートクラウドにと
思われるかもしれませんが…今までに何度もトラブルを経験しておりますが、
中国では自社でコントロール出来ないと非常に不安です。
トラブル対応は技術的な事より交渉が非常に大変です。

プライベートクラウドを構成しているOSやアプリケーションは
すべてオープンソースを利用しておりノウハウも十分ありますので
メーカーからハードウェアを調達する以外は自社で対応しております。
最新のハードウェアに新たにプライベートクラウドが構築出来たら
仮想サーバーの移動です。仮想サーバーを停止してイメージを
コピーし移行完了です。とても簡単です。何の問題も無いので
逆に不安になります。インフラは必ずトラブルが発生するものですので
出来る事なら早目にトラブルが出尽くして頂くのが良いです。

このプライベートクラウドでWeb会議システムが稼働しております。
自社運用ですので情報漏洩もなく安心安全です。IPv6にも対応済みです。
お試し頂く事も出来ます。

https://www.evolutionnetworks.net/service/en-meet.html


■ あとがき

7/7(水)の中国時間08:00に中国のバックボーンネットワークで何か
変更作業したようで一部の経路で遅延が約3倍になり悪化しております。

https://www.evolutionnetworks.net/support/status.html