検索:

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はいかがでしょうか?
だたしオープンソースですので「ただより高いものはない」
ということにご注意ください。
何を隠そう弊社(私)が…身をもって体験しました。

Windows Server 2012/2012 R2 サポート終了

10年以上という長期にわたって提供されていた WindowsServer2012/2012R2の
サポートが2023年10月10日に終了します。

思えばその昔…最初にファイルサーバーを構築した時に使用したOSは
Novellというメーカーの「NetWare 3.12」でした。その次が「NetWare 4.11」です。
オフィスの片隅にサーバルームというパーティションで囲んだだけの部屋がありました。
そこに業務用フリーザーみたいな物体がありました…それがファイルサーバーでした。
その時代..オフィスでは「緊急事態発生!サーバーが落ちた!何とかしろ!」という
怒号が飛び交うことがありました。ファイルサーバー停止=業務停止という
ことになりそれはもう大騒ぎでした。原因で多かったのは熱暴走だったと思います。
業務用フリーザー…でなくファイルサーバーの前には扇風機が何の違和感もなく
鎮座している時代でした。

Microsoft社がWindowsNT Server 3.51を発売したころには
NetWareから移行する事が多くなりなした。
そのころは…Microsoft社がサーバーOS?なんて時代でした。
とにかく不安定でWindowsNT Serverは毎日起動する…というのか私の周りでは常識でした。

WindowsNT Serverのサーバーの落ち方も豪快です。
突然サーバーに接続されているモニターがブルー画面になります。
そこに白い文字で英語のような長い呪文が表示されます。よく読むと最後に
「管理者に連絡しなさい…」という指示が表示されています。そこで管理者を
探すため周囲を見渡し…ん?あれ?もしかして自分?ということが判明し
私の顔面がブルーになった思い出があります。
それがトラウマとなり今でもマ○クロソフト社のサーバOSは嫌いです。
サーバーOSは安心のLinuxが私のデフォルトです。

前置きが長くなりましたが…その後
WindowsNT Server 3.51
WindowsNT Server 4.0
Windows2000 Server
WindowsServer 2003/2003R2
無かったことにして…
WindowsServer 2012/2012/R2
無かったことにして…
WindowsServer2022
というようにファイルサーバーのOSをアップデートしてきました。
20年前からは10年毎にアップデートというパターンです。
WindowsServerの基本的な機能しか必要無いのでセキュリーティーパッチが
提供されいれば十分です。

まずは試用版のWindowsServer2022をダウンロードして色々と基本的な
機能が問題無いことを確認です。

その後ActiveDirectoryにWindowsServer2022を追加して2012R2と混在し
問題なく稼働することを確認です。

弊社は日本と中国のデーターセンターにファイルサーバーがあります。
日中間でファイルサーバーのデーターを複製し同期しております。
そこにWindowsServer2022のファイルサーバーを追加してデーターを同期
出来ることを確認です。

最後にWindowsServer 2012R2を停止して移行完了…
ライセンを購入して認証もお忘れなく…


■ あとがき

移行中はWindowsServer 2012R2と2022が混在させた状態で安定稼働を
確認し慎重に移行作業を実施しました。
私失敗しないんです…というのはこの業界ではありえないので
私失敗しても大丈夫なんです…という状況にするのが基本です。

ランサムウェア対策サービス

IT系のニュースサイトでランサムウェア被害のニュースがさらに
増えているように思えます。

弊社ホームページに「ランサムウェア対策」サービスを追加しました。
https://www.evolutionnetworks.net/service/ransomware.html

ランサムウェアに感染すると重要なデーターがロックされに
アクセス出来なくなります。データーを適切な方法でバックアップし、
OSやウィルス対策ソフトのウィルス定義ファイルを最新の状態にする。
さらにUTMやサーバーを常時監視することで感染リスクやダメージを
最小限にするサービスです。

【データーを複数のデーターセンターへバックアップ】

例えランサムウェアに感染しファイルが開けなくなっても
バックアップデーターが感染していなければバックアップを
取得した時点までは復旧可能です。ただしバックアップ先が
お客様のサーバーに接続されているハードディスクやPCなどの
端末からアクセス出来る環境ではバックアップデーターまで
感染するリスクがあります。そこでお客様のサーバー以外からは
アクセス出来ない遠隔地のデーターセンターにある
プライベート・クラウドにデーターを複製することで対策をします。
さらにお客様のサーバーからアクセス出来ない別のデーターセンターへ
複製しプライベート・クラウド上でスナップショットを取得することで
データーを保護します。

【WindowsUpdateとウィルス対策】

ランサムウェアに感染するリスクを下げるためにはお客様の
サーバーやPCのOSとウィルス対策ソフトのウィルス定義ファイルが
最新である必要があります。これらの対策に必要なサーバーを
すべてデータセンターのプライベート・クラウドにあるサーバーから
サービスを提供します。

【稼働状況とトラフィックの監視】

ランサムウェアに感染した場合、いかに早く対応し被害の拡大を
抑えるかが重要です。UTMやサーバーを常時監視することで
通常とは違う状況に早く気がつくことで対策します。
例えばCPUの使用率状況や回線使用率の急上昇などに
気がつけば被害の拡大を抑えられる可能性があります。


■ あとがき

日本では未だに「インターネットVPNは危ない」
「バックアップはローカルで取得する」という方針の企業があると聞いて
驚いております。ほんの一部の企業とは思いますが…

コロナ禍でのハードウェア更新

新型コロナウィルス感染症により中国出張が非常に難しくなってから
早2年以上となりました。今、私は日本におります。中国のデーターセンター
にある弊社サーバーの更新作業…出張しようと色々調査しましたが
リスクが高いので断念しました。ということでフルリモートで対応することに
なりました。

まずは購入するスペックを決め現地スタッフに発注を依頼します。
すると数時間で見積もりが届きます。日本のように数日、数週間、数ヶ月
かかるということはありません。ですが、発注しようとすると
お約束で「今在庫がない」「それは生産停止になりました」ということが
90%以上の確率で発生します。ですのでこれを考慮し予め様々なスペックを
考えておきます。納期もコロナ禍のロックダウンで輸送が大幅に遅れる
ことを考慮する必要があります。

ハードウェアが納品されたらまずは開封作業です。その前に既に箱が
開封済でないことを確認する必要があります。
オプションのメモリやハードディスクなどは別のサーバーから取って来た物を
納品されるということが良くあるので、箱に入っていて開封済みでないことを
確認する必要があります。

機器の設定はリモートから実施します。現地スタッフに購入した機器を
オフィスのLANに接続してもらいます。そして初期設定情報が書かれた
資料を送ってもらいます。情報がそろえば日本からリモートで
接続しOSのインストールです。弊社の日中間ネットワークは
常時数十Mbpsでているのでインストールはストレスなく作業出来ます。

サーバーの設定作業完了後、機器をデーターセンターに搬入です。
コロナ禍ですので入館手続きに時間がかかります。
特にこれから10月にかけ北京で会議があるので、データーセンターに
機器を搬入出来なくなる時期があり注意が必要です。

これで作業は完了です。リモートでも簡単にハードウェアの更新が
出来ます…というのは弊社が20年近くの実績があるからです。
日本のIT部門が中国のIT部門に依頼する場合、言語や文化の違いによる
意思疎通がうまくいかない場合があります。中国に日本語が出来る通訳が
いてもITの知識が無いとこちらがやりたい事を伝えるのが非常に困難です。


■ あとがき

前回、書いたようにランサムウェアの感染が拡大しております。
ハードウェアの更新だけでなくセキュリティー対策の強化など
中国の現地企業のITでお困りであればご相談ください。
日本語で対応し(私が)中国では現地スタッフが対応します。

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を
検証したりサーバーをリプレースするなどの作業があり半年以上かかりました。
ハードウェアの交換などは現地のスタッフが作業しましたので私は一度もデーターセンターへは

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