検索:

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

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

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

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

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

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

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

【WindowsUpdateとウィルス対策】

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

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

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


■ あとがき

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

ホームページリニューアル

先日、ホームページをリニューアルしました。
なんと…10数年ぶりです。会社設立時から私がエディターでHTMLファイルを
書いております。その昔はCSSでデザインするという方法が無かったので
HTMLファイルにすべて書いておりました。

私はインフラエンジニアでありWebデザイナーではありません。
そもそもIT業界へはプログラマーになるために入ったのですが、
なぜかサーバーやネットワークなどのインフラの仕事をしております。
そのような経緯もありホームページ作成やWebアプリ開発なども
時間のある時にしております。

今やPCからではなくスマードフォンやタブレット端末から
ホームページへアクセスする方が多いので以前からリニューアルを
検討しておりました。そしてようやくHTML5 + CSS3で書き換えました。
WordPressではなくアプリの開発環境を使用して書いております。

今回改めてHTML5 + CSS3を勉強してみたのですが、以前はJavaScriptを
駆使していたのが今やCSS3で出来ることが多くなりました。
スマホ対応もCSS3ファイルで対応可能というのに時代の流れを感じております。


■ あとがき

今風になったホームページをぜひご覧ください。
https://www.evolutionnetworks.net

リモートワーク 作業環境編

新型コロナウィルスの拡大が収まる気配がしません。
日本ではリモートワークが大企業を中心に導入がすすんでいるようですが、
私は日本と中国を行き来しており10年以上前からオフィス以外でも仕事をする
今で言うところのリモートワークを実践しております。

自宅で仕事する場合に必要となる物…まずは机とイスです。
オフィスでもそうですが、特にイスは長時間座って疲れない物がベストです。
イスの高さ調整を色々試しベストポジションが決まると長時間座っていても
疲れづらく仕事に集中出来ます。

次にメインであるPCですが、仕事柄どこでも作業出来なければならないので
私はモバイル・ノートPCを使用しております。外付けマウスではなく
トラックポイントが有るとマウスを操作する度にキーボードから手を
離す必要がないので作業効率が上がります。さらにマウスを持ち運びする
必要がありません。

そしてかかせないのが…外付けモニターです。
モバイル・ノートPCだと最近は画面の縁が狭くて画面が昔より大きくなって
おりますが…デスクトップPCのモニターに比べ作業スペースは狭いです。
そこでノートPCに外付けモニターを接続すると画面を拡張出来るので
ノートPC側の画面でメールをチェックしつつ外付けモニター画面側で
SSHクライアントやExcelなどを開いて作業すると効率が全然違います。

そしてあると便利なのがタブレットです。動画ニュースをチェックしたり
Webセミナーに参加したりなど便利です。他のスタッフとの連絡は基本的に
チャットですが、タブレットはWeb会議にも活用出来ます。

私の場合、机、イス、外付けモニターのセットを、日本と中国の数カ所に
設定してあり快適に仕事が出来る作業環境を事前に準備してあります。
ただ中国で一番問題になるのはこのような設備ではなくネットワークです。
いくら快適な作業環境でもネットワークが遅いと仕事になりません。
弊社ではそのような問題を解決するサービスをご提供しております。

【リモートワーク in チャイナ】
https://www.evolutionnetworks.net/service/remotework.html


■ あとがき

私の仕事はサーバーやネットワーク機器の設定・運用ですので
基本的に人と会話するより…機器と話していることの方が多いです。

ホームページのURLを変えずに高速化

「日本のサーバーに中国語のホームページを置いているが
中国からのアクセスが遅い」または「日本にある社内向けのWebシステムに
中国からのアクセスが遅い」という相談を受けることがあります。

中国語のホームページを日本のサーバーで運用するのは
追加であまり費用がかからない。ICPの申請が必要ないなどメリットが
ありますが、中国からのアクセスが遅いのであればチャンスを
逃すことになります。日本にある社内向けWebシステムへのアクセスが
遅いのであれば業務に影響がでると思われます。

ある程度の規模であればCDN(コンテンツデリバリーネットワーク)の
利用が一般的と思いますが、それなりの費用がかかります。

費用をおさえて解決するのであれば中国向けのURLを用意し
中国にあるサーバーにデーターを置くことで解決するかと思います。
ただしURLが変更になったり日本のデーターとどのように同期するか
などの問題が発生します。

そこでこれらの問題を解決する方法として中国にあるDNSサーバーを
利用しているPCやスマートフォンなどの端末からは中国のサーバーへ
アクセス、それ以外は日本のサーバーへアクセスするという仕組みです。
データベースサーバーは日本に置いておき外部に公開するWebサーバー
またはProxyサーバーを中国に設置するという構成になります。
具体的な構成については個別にご相談頂ければと思います。
弊社のクラウドサービスはこの方法で運用しております。


■ あとがき

今年はスマートフォン・タブレット向けの開発にチャレンジします。