検索:

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

送信ドメイン認証 – DMARCへの対応

スパムメール、ゴミメール、なりすましメール等々….
迷惑メールが毎日届きます。ただしほどんどの迷惑メールは受信ボックスへ
配信される前にスパム対策のメールゲートウェイによって拒否および隔離
されていると思います。
SPF,DKIM…昔から様々な対策が導入されております。
今はメールはクラウドを利用されている企業様がほどんどだと思いますが、
最近、クラウド事業者から「DMARCへ対応してください」という連絡は
ありませんでしょうか？

DMARCとは簡単に言えば迷惑メール対策です。
DMARCを導入するにあたり「SPF」と「DKIM」を導入する必要があります。

【SPF(Sender Policy Framework)】
ドメインを管理しているDNSサーバーにメールサーバーの
IPアドレスを登録し公開します。相手側メールサーバーがメールを
受信する際、送信元ドメインのメールサーバーのIPアドレスが
公開されているものと一致するか確認するという仕組みです。

【DKIM(DomainKeys Identified Mail)】
公開鍵暗号技術を利用します。送信するメールに「秘密鍵」で作成した
電子署名を追加します。相手側メールサーバが受信する際、
DNSサーバーで公開されいる「公開鍵」で電子署名を検証することで
電子署名の作成者の身元が確認出来ます。
さらにメールデーターの改竄も検知することが出来ます。

【DMARC (Domain-based Message Authentication Reporting and Conformance】
「SPF」と「DKIM」の検証結果により受信側がメールの扱いをどうするか
決める仕組みです。ドメインを管理しているDNSサーバーで
DMARCレコードとして公開します。

クラウドを利用されている企業様はWebの管理画面でDNSレコードを管理
していると思いますが、DMARCへの対応もWebの管理画面から
公開鍵、秘密鍵を作成しDNSレコードで公開という方法になるかと思います。
クラウド事業者によって方法が色々ですのでDNSとメールの仕組みを
理解していないとDMARCへの対応が難しいかもしれません。
お困りであればご相談ください。

■ あとがき

2024年2月からGmailがSPF/DKIM/DMARCに対応していないドメインからの
メールを一日5000件までに受信が制限されております。
今後はGmail以外にもGoogle WorkspaceやOffice365も同様に
制限されるかもしませんので早めに対応を！

Windows Serverのライセンス再認証

WindowsServer2022の検証作業と移行作業が無事完了しました。
が…OSは問題なかったのですが、諸事情によりどうしてもあるサーバーの
OSを再インストールしなければならないことになりました。
お客様へのサービスには影響無いためそれほど急いでする作業ではありません。

とあまり緊迫感なく作業していたのですが、OSを別のサーバーで再インストール
したために画面右下に「…Windowsのライセンス認証を行ってください。」という
表示が出ます。もちろんライセンスは購入済みですのでライセンス認証を
実施したのですが…ダメです。何度やってもダメです。
おそらくハードウェアを変更したのが原因と思われます。
ハードウェアと言っても弊社のプライベートクラウド上にある仮想マシンです。

まずはGoogle大先生に聞いてみます。色々と解決方法を試したのですが、
どれもダメでした。次にマイクロソフト社のホームページでライセンスについて
調べてみます…昔から思っているのですがライセンスが非常に複雑です。
これを考えた人以外で理解している人はいるのでしょうかと思うくらいです。
ライセンスについての説明文を読んでも複雑過ぎて理解不能…という
より読む気になれません。そのうちに不安になってきました。購入したのに使えない…

ライセンス購入元へ問い合わせてみます。が…日本だと問い合わせてしてから
2～3日…遅くて1週間以上回答が無い場合があるのであまり期待出来ません。
ということでマイクロソフト社へ電話で直接問い合わせることにしました。
ホームページで問い合わせ電話番号を調べます。そこに電話すると…
「電話によるサポートは終了しました…」ん？え？
ライセンス認証終了していないのですが…

再度Google大先生で…今度はライセンス認証の電話番号を調べてみます。
ありました。早速電話です。番号を選択するようにとのガイダンスが
流れますので該当する番号を押していきますが…何度やっても人間様に
出ません何度もかけ直し押す番号を変えても機械様しか出てくれません。
格闘すること1時間…ようやく人間様が出てくれました。

電話サポートによると…まずサーバー上でコマンドを打ち込む…
すると数十桁の番号が表示されます。それを電話のボタンで入力することで
ライセンスが認証されるとのことです。慎重に番号を押していきます。
ようやく再認証されました。格闘すること2日間…非常に疲れました。
精神的に…

■ あとがき

WindowsServerのアップデート完了と安心していたら…次はLinuxです。
RockyLinux9のサポート期限2032/05/31…ただいまこれを検証中です。

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

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

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

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

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

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

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

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

■ あとがき

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