検索:

FortiGate Eシリーズサポート期限対応 – データーセンター設置編

新しいFortiGateの設定が完了していよいよ設置作業です。
事前にお客様へはメンテナンスのためサービスを停止するとの連絡は
してあります。夜間、いよいよ作業開始です。

上海スタッフとデーターセンターに入館します。
事前にケーブルの配線方法は資料を作成し共有していますので
問題ないはずですが…「LANケーブル全部外して綺麗にしましょう」と
提案が…言うのは簡単だけど…と心の中で叫びながら
でもハードウェアの管理をしているのは上海スタッフですので
提案の受けいれることにします。数百本あるLANケーブルを外すために
サーバーを停止します。CloudStackで構築したプライベート・クラウド
ですので、まずは仮想サーバーを停止します。
次に物理サーバーを停止します。物理サーバーを完全に停止する
ということは滅多にないと思いますが、こんな時に限って重要な
サーバーが一生起動しなくなるということがあるのはなぜでしょうか?
幸い今回はそのような事はありませんでしたが…

今回はSwitchの設定変更があります。なるべく停止時間を短くするために
事前に決めた手順どおりに焦らずでも急いで設定変更します。
そしていよいよFortiGateの設置、交換作業です。ここまで奇跡的に
問題なくすすみました。

しかし…ここで欲を出したのが良くなかった。使わなくなったサーバーから
メモリを取り出し既存のサーバーに追加しましたが、OSが起動しません。
何度もサーバーを取り出して戻すという作業を繰り返します。
サーバーがラックの上の方に設置してあったため重いサーバーを持ち上げている
スタッフの手がプルプルしています。その下で作業している
私の頭に落下したら痛いので私もサーバーのラッキングを手伝います。
結局、メモリが不足していたわけではないのでメモリ追加は中止にしました。
安定稼働が最優先です。作業がすべて終了しデーターセンターを出た頃には
日が昇っておりました。

そして少し休憩してから上海市内にあるお客様のオフィスや工場を
訪問しFortiGateの交換作業を実施しました。

—————————————————————————————–—————————

■ あとがき

————————————————————————————–——————————

無事に上海での作業が終了し帰国出来ました。
でもまだまだ続きます。FortiGateの交換作業が…

FortiGate Eシリーズサポート期限対応 – 設定編

久々の上海を満喫する暇もなく目の前に積み上げられたFortiGateの前で
しばらく考えて….いるふりをしております。
本当はハングアップしているだけです。

過去の資料を確認してみたらJuniperNetworksのSSGシリーズから
FortiGateへ移行してから早10年です。IPsecVPN,IPv6,IPoE対応
さらにSSL-VPNサポート終了の対応など色々ありました。

そして今回はFortiGate EシリーズとFortiOS7.2のサポート期限への
対応で機器の入れ替えです。いつもはリモートで機器を…ではなく
上海スタッフをリモート操作して作業しています。
「はい。FortiGateの1ポートをSwitchの5に接続して」とか
「あっ設定間違った。FortiGate初期化して」といった感じですが、
データーセンターのFortiGateの切替は失敗出来ないので
私が現場で作業することにしました。

FortiOS7.4からライセンスの管理が厳密になったようでライセンス期限が
切れているとアップグレードもダウングレードも出来ません。
さらに箱から出し何も設定されていない状態だと
インターネット回線とFortiCloudのアカウントが無いと設定すら出来ません。
と..思ったのですが、実は方法があったようです。
FortiOS起動前のBIOSで「一時的」にFortiCloudとの認証を無効にして
後から認証するようにすればとりあえず設定作業は出来ました。
もちろん後からインターネットに接続して認証する必要があります。

新しいFortiGateの設定手順ですが、まずは先程のインターネットに接続して
FortiCloudとの認証が終わってからの作業について…

既存のFortiGateの設定ファイルをダウンロードします。
それから新しいFortiGateのGUI管理画面である程度の設定していきます。
すべてをGUIで設定すると非常に時間がかかりますし、タイプミスもするので
FortiGateとSSHまたはコンソールケーブルで接続してコマンドを
入力して設定するCLIで作業します。コマンド入力というか設定ファイルの
コピペです。設定ファイルの一部をコピーしてCLIで貼り付けるという方法です。
だだしこれだけで終わりというわけではありません。
FortiOSのバージョンを7.2から7.4や7.6等にアップデートすると
微妙に設定が違いそのままだと思い通りに機能しないことがあります。
そのため修正が必要です。この部分が職人技となります。
設定ファイルをじ~っと見ていると…わかるんです。違いが…

設定が終われば箱詰めして中国各地への発送準備完了です。これを永遠に続けます。

—————————————————————————————–—————————

■ あとがき

————————————————————————————–——————————

弊社でFortiGateを設定して…というのは問題ないのですが、
日本や中国本土以外の東南アジアなどです。輸出入の関係で弊社から
FortiGateを発送することが出来ませんので現地で調達して頂いて
弊社からリモートで設定するのですが、これが大変です。

FortiGate Eシリーズサポート期限対応 – 上海出張編

久々の上海出張です。
航空会社のホームページでオンライン・チェックインを済ましたのですが…
荷物を預けるのにカウンターに並んで紙の航空券を取得しました。
オンラインの意味が良くわかりません。
出国審査場では端末にパスポートを読み込ませるとゲートが開いて出国となり
時間帯にもよると思いますが、すんなりと通過出来ました。

そして中国への入国方法…忘れました。
最近、機内では紙の入国カードは配布されなくなったという情報を
聞いていたので事前にスマホでオンライン申請してQRコードを取得しました。
入国審査場で審査員に顔をじ~っと見られて横にある端末のカメラに向って
微笑めば…指紋は何度も採られているので(悪事は働いておりません)通過です。
QRコードですが、結局出国するまで一度も使っていません。
常にカメラで監視しているので貴方の事はすべてお見通しということでしょうか?

空港に到着してまず気付いたのは…電気自動車が多い。
特に空港の駐車場は多かったです。ほとんどが知らないメーカー
だたし共通しているのが…デカイSUVが多いです。デカイ=偉い=強い
ということで好まれているのでしょうか?
政府からの補助金があるようで新車が沢山走っております。
ちなみに私は小さくてスゴイ馬力のドッカン・ターボ車が大好きです。

上海のスタッフに空港まで迎えに来てもらったのですが、
電気自電車…ではなく車で…そこで気がついたのが、スマホのナビアプリの
精度がスゴイことです。今、どの車線を走っているのか正確にわかります。
昔からあるのですが、高架道路を走っていると電子掲示板があり車のナンバーが
表示されています。手前の車線変更禁止区間で違反をすると…
「はい。アウト!」という意味らしいです。

それから日本でも増えてきましたが、駐車場の出入り口はカメラでナンバーを
読み取り自動で入出庫を記録しております。
ある日上海スタッフと商業施設へ行って地下駐車場に車を停めました。
出庫する時の支払いは…QRコード決済です。便利です…で終わらないのです。
地下でスマホの電波が弱いのかORコードがうまく読み込めず後ろは大渋滞です。
そのうちクラクションや罵声が…

—————————————————————————————–—————————

■ あとがき

————————————————————————————–——————————

今回は作業でスケジュールがいっぱいで街に出たり観光はしておりません。
ひらすらFortiGateの設定をしておりました。
滞在した場所の周辺にオフィスビルが激増しておりました。
景気が良いのでしょうか?

FortiGate Eシリーズ サポート期限

弊社のお客様は中国全土および東南アジアに複数の拠点があるため
今年は移行作業で忙しくなりそうです。

大まかな手順は下記になります。

1.FortiGateの設定ファイルを取得
2.取得した設定ファイルを元に新しい機器を設定
3.現地で機器の交換作業
4.動作確認
5.リモートからの監視

FortiOSは7.4からはライセンス期限が過ぎている機器のアップデートが
出来なくなっておりますのでご注意ください。

中国および東南アジアに拠点がある企業のIT担当者様は
日本から出張して切り替えるのが大変かと思います。
日本のように希望する機器を納期どおりに手配出来ない…
現地の業者に移行を依頼しようとしてもうまく伝わらない等々
色々と悩みがあるかと思います。
そこは弊社におまかせください。これを書いている私が機器の設定をします。

—————————————————————————————–—————————

■ あとがき

————————————————————————————–——————————

Windows Server 2016の延長サポート期限が2027/1/12ですので
オンプレミスで稼働しているサーバーの切り替え作業もあります。
日本ではファイルサーバーにクラウドサービスを利用している企業が
多いと思います。中国のクラウドサービスは技術には問題がありませんが…
ということなのか?中国ではまだオンプレミスで稼働するサーバーがあります。

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