検索:

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ではなく私がハングアップしてしまうこと間違いないです。