検索:

CloudStackのアップグレード – その後

新しいCloudStack環境は安定して稼働しております。
というのは間違いないのですが….

ある日…Webサーバーがダウンするという障害が発生しました。
ロードバランサーの下にWebサーバーが複数台ある構成ですので
ホームページは閲覧可能な状況ですがこれは問題です。

ログを調べたところメモリが不足したためOSがWebサーバーを自動で
シャットダウンしたというメッセージがありました。
そこでメモリを増強し様子をみることにしましたが…翌日またダウンしました。
そこでWebサーバーのメモリ関連のパラメーターを調整しました。
すると…ダウンする頻度は格段に減りましたがまだダウンします。
メモリは十分のはずなのにおかしいです。
コマンドでメモリの状況をじっくり確認したところ…なんと
3GBしか認識していません。他のサーバーを確認したところ同じ状況です。
これはおかしいです。異常です。問題です。

OSのログを調査しても原因が特定出来ません。
これはもしかしてノードサーバーの問題？具体的には「KVM + QEMU」の設定に
問題があるのかと考えました。設定ファイルを見てもパラメーターが多すぎて
調べるのに時間がかかります。そこでGoogle先生…ではなく今は
ChatGPT先生の出番です。最初はBIOSのバグが疑わしいとか32bitOSは4GB以上
認識しないという回答でしたが、KVMとQEMUを管理するlibvirtdやQEMUの
設定について質問すると…色々と詳しく提案してくれます。
スゴイですが…解決しません。

ノードサーバーを疑い調べていたのですが…今どき「KVM + QEMU」の
設定でデフォルトでメモリが3GBになっているわけないと…
これはもしかしてCloudStackコントローラー？
そこでCloudStackのメモリ関連のパラメーターを調べてみると…ありました。
何やらノードサーバーを効率よく使うためのパラメーターが
デフォルトでONになっていました。それをOFFにしてからクラウドコントローラーを
再起動しすべての仮想サーバーを停止→起動することで…解決しました。

——————————————————————————————————————–
■ あとがき
——————————————————————————————————————–

まさかすべてのサーバーがメモリの上限3GBで稼働していたとは…驚きです。

今回はバグではなく設定が原因でした。

CloudStackの最新版は非常に安定しております。

プライベートクラウドの導入でお困りでしたらご相談ください。

CloudStackのアップグレード – 仮想サーバーの移行

新しいCloudstack環境が完成したところでこれからが本番です。
そうです…稼働中の仮想サーバーを移行しなければなりません。

手順は下記です。

  1. 旧環境の仮想サーバーを停止
  2. 旧環境で「1」で停止た仮想サーバーのテンプレートを作成
    3.「2」で作成したテンプレートをWebサーバーへアップロード
  3. 新環境でテンプレートを作成(Webサーバーからダウンロード)
  4. 新環境で「4」で作成したテンプレートから仮想サーバーを作成

基本的にはこれで移行出来ます。この作業を1台づつするので時間はかかります。

今回、物理サーバーは追加せずに移行作業を実施しました。クラウドですのでリソースには

余裕があるため例えば5台あるノードサーバーを3台に減らし2台を新しい環境で使用するという

方法です。

問題はストレージサーバーです。物理サーバー2台1組を1セットとして稼働していますが、

仮想サーバー移行作業中はどうしても別の物理サーバーセットにデーターを移行したい場合が

あります。容量も数テラありますので時間がかかります。その場合、rsyncコマンドでデータを

一括コピーします。コピー出来てこれで終わりではありません。
CloudStack上でストレージのサーバー名を変更しなければなりません。
GUIでは出来ません。しかもマニュアルにも書かれておりません(と思います)。
どうするかと申しますと…絶対やってはいけないデーターベースを直接更新するという方法です。CloudStackの古いバージョンでは色々とバグがありたまに実施していましたが、

これを失敗するとSQLコマンド一発で完全にクラウドが破壊されます。
会社が倒産するくらいの破壊力です。これは非常に危険ですので絶対やってはいけません。
弊社でも通常やりません。

そして1ヶ月程でようやく仮想サーバーの移行が完了し終了です。

■ あとがき

今回の環境構築、移行作業…すべて作業は日本からリモートで実施しました。

しかも日本と中国のデーターセンターへは1度も行っておりません。

CloudStackのアップグレード – 環境構築 クラウドコントローラー編

CloudStack環境を構築するには「ストレージサーバー」「ノードサーバー」
「クラウドコントローラー」が必要です。今回はクラウドコントローラーです。

CloudStackでのクラウドコントローラーは「Cloudstack Management Server」です。
ChatGPTによると「Apache CloudStackの中心的なコンポーネントであり、
クラウドインフラストラクチャの管理を担当するサーバーです。CloudStackはオープンソースの

クラウドコンピューティングプラットフォームであり、主にIaaS（Infrastructure as a Service）を

提供します。」とのことです。

クラウドコントローラーに弊社で使用しているOSはRockyLinuxです。MySQLデータベースと

CloudStackの管理サーバーをRockyLinuxにパッケージ管理ツールであるdnfでインストールします。

複数サーバーのストレージをリアルタイムに複製するオープンソースのDRBDを
インストールします。クラスターを構築するためにオープンソースのPacemakerとCorosyncも

インストールします。これで通常は2台のうち1台がクラウドコントローラーとして稼働し

故障した場合、データーベースやIPアドレスが故障していないサーバーへ引き継がれ稼働し続けます。
さらにWebサーバのApacheもインストールしております。Apache,DRBD,Pacemaker,Corosyncは

ソースコードからインストールしています。

ここまでくるとクラウドとして稼働させる準備が出来ました。
後は、CloudStackの管理画面でゾーン、クラスタ、ポッド、ネットワークを作成し

ストレージサーバー、ノードサーバー等を追加すればCloudStackでプライベートクラウドが完成です。

後はプライベートクラウドにisoファイルをアップロードし仮想サーバーを作成してみます。

仮想サーバーを稼働させたまま別の物理サーバーへ初めて移動(ライブマイグレーション)出来た時は

感動します。

最後に、現在本番稼働しているCloudStack上で稼働している仮想サーバーを移行します。

今回作成したCloudStackとは別環境ですので手動で移行する必要があります。

これが非常に大変です。1ヶ月以上かかりました。

次回は最終回「仮想サーバーの移行」についてです。

■ あとがき

プライベートクラウドが完成し仮想サーバーを移行する前にやることがあります。

障害テストです。クラウドコントローラーやストレージサーバー、ノードサーバーのOSを

いきなり停止したり意図的に障害を発生させ復旧させるという検証です。実は検証中にこれで

何度か復旧不可能になり再構築を何度もしました。そうすることでノウハウが蓄積されます。

逆に何も問題なく本番稼働することコワイです非常に…

CloudStackのアップグレード – 環境構築 ノードサーバー編

CloudStack環境を構築するには「ストレージサーバー」「ノードサーバー」
「クラウドコントローラー」が必要です。今回はノードサーバーです。

ノードサーバーとは仮想サーバーをホストする物理サーバーです。
簡単に言うと仮想サーバーにCPU、メモリなどのリソースを提供するサーバーです。

VMware,Xen Server, KVM, XCP-ng, ベアメタル等から選択可能で、弊社ではKVM(OSはRockyLinux）を

選択しました。具体的には「KVM + QEMU」を使用しております。
ChatGPTによると「QEMUが仮想マシンを管理し、KVMがハードウェア仮想化の性能を引き出します。この組み合わせにより、高速で効率的な仮想化環境が実現します」とのことです。

ノードサーバーの作成にはRockyLinuxにパッケージ管理ツールであるdnfでClouStackエージェント等をインストールしていきます。こう書くと簡単なようようですが、弊社ではOpenSSL,OpenSSH,BIND等は
ソースコードからインストールしています。インストールする順番やバージョンによっては

ClouStackのエージェントがエラーで稼働しない等の問題が発生するためあらゆるパターンで

検証し最終的に問題は解消しました。今回の作業ではここが一番時間がかかりました。

ノードサーバーだけでも仮想サーバーを作成出来ますが、これだけだとクラウドっぽくありません。

GUIの画面でクリックしてサーバーを作成するとか仮想サーバーを稼働したまま別の物理サーバーへ
移動(ライブマイグレーション)するなど…それらはクラウドコントローラーの役割です。

次回は「クラウドコントローラー」についてです。

■ あとがき

将来的にサーバーCPUやメモリが不足した際はハードウェアを追加または交換すれば拡張可能です。

これは非常に便利です。

CloudStackのアップグレード – 環境構築 ストレージ編

CloudStack環境を構築するには「ストレージサーバー」「ノードサーバー」
「クラウドコントローラー」が必要です。今回はストレージサーバーです。

ストレージサーバーのハードウェアは2台1組として構成します。
もちろんストレージはRAID構成です。弊社で使用しているOSはRockyLinuxでそこでNFSサーバーを

稼働させます。RAID以外にも冗長化のため複数サーバのストレージをリアルタイムに

複製するオープンソースのDRBDをインストールします。クラスターを構築するために

オープンソースのPacemakerとCorosyncもインストールします。これで通常は2台のサーバーが
ストレージサーバーとして稼働し1台故障した場合、データーやIPアドレスが故障していない

サーバーへ引き継がれ稼働し続けます。

滅多にハードウェアが故障して切り替わるということは無いと思いますが、実際に故障した場合

どうなるかと申しますとこのストレージサーバーを使用しクラウド上で起動している仮想サーバーは

ほぼ停止します。だたしデーターは消えていないので起動しなおせば復旧します。
このようにストレージサーバーが故障すると仮想サーバーが停止するなどの影響がありますが、

障害は絶対発生しないということはありませんのでデーターが消えないことと早く復旧させる事が

重要と考えております。

突然サーバーの電源が落ちた場合、運用良く問題無い事がありますが、大抵2台のサーバー間で

データー不整合が発生する場合があります。そのような時、ログを調査し原因を特定してコマンドを

打ち込んで復旧させるのですが、これが非常に難しく何度も障害を経験していないと慌ててしまい

復旧に時間がかかります最悪は復旧しないということにもなりかねません。

弊社は20年以上もこの構成を使用しておりますので様々な障害にも対応してきました。

ミッションクリティカルなシステムにはストレージ専用のサーバーを導入し保守をメーカーや

代理店にお願いすると思います。高価なだけあって1台くらいの故障では何の影響も無い

構成になっていると思います。

中小規模のシステムであれば中途半端にストレージ専用のサーバーを導入するとシステムが

ブラックボックスになって自社では対応することが出来ず。障害発生時、保守担当者が来るのを

待つということになります。さらにサーバー設置場所がデータセンターであれば入館手続きに

手間取って復旧が遅れるという最悪の自体にもなりかねません。

弊社では日本以外に中国でもCloudStackを導入しているので
ハードウェアの故障以外、自社で対応出来るように基本的にオープンソースを使用しております。

次回は「クラウドコントローラー」についてです。

■ あとがき

サーバーの中でもデーターを格納しているストレージサーバーの故障が
一番怖いです。障害時はOSではなく私がハングアップしてしまうこと間違いないです。

CloudStackのアップグレード – 準備編

弊社がデーターセンターに導入しているCloudStackは、
プライベートクラウドを構築、運用するためのオープンソースのソフトウェアです。

最初に導入したのは2003年です。2021年にCentOS6のサポート期限切れにより
OSとCloudStackのアップグレード作業を実施しました。

今回もCentOS7のサポート期限切れによるOSとCloudStackのアップグレードです。
CentOS7の後はCentOS8にする予定でしたが、CentOS8が突然サポート終了と
なりました。そのため急遽、まずはクラウド上で稼働しているOSをRockyLinuxへ移行しました。
そしてとうとうCentOS7のサポートが2024/06末で終了しました。

CloudStackを稼働させるにはOS以外に様々なソフトウェアを
インストールする必要があります。例えばサーバーを二重化するための
クラスタリングソフトなどです。まずはそれらのソフトウエアが
RockyLinux上で問題無く稼動するか検証する必要があります。
正常に稼働するだけではだめで障害発生時から問題なく復旧するかも検証する必要があります。

検証環境を構築しテストすること1ヶ月…RockyLinuxでCloudStack以外の基盤となる

ソフトウェアが問題なく稼働することが確認出来ました。

■ あとがき

2023/11にBroadcom社によるVMware社の買収か完了して以降
それまで提供していた買い切り型の永続ライセンスを廃止し、
サブスクリプション（定額課金）型になったようで
実質値上げに等しいというニュース記事を読みました。
今後の移行先としてCloudStackはいかがでしょうか？
だたしオープンソースですので「ただより高いものはない」
ということにご注意ください。
何を隠そう弊社(私)が…身をもって体験しました。

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年以上使用しておりますが、

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