Editionライセンスで稼働していて、今ではかなり重要な経路を担当しています。サーバ用デフォルトゲートウェイOffice365向けインターネットゲートウェイメールゲートウェイMastodon/Misskeyインスタンス用対外部Webゲートウェイ内部ネットワーク/DMZ間のボーダールーター(OSPFv2)IPSにも拘わらず長年シングル構成をとっていました。HA構成を挑んでうまくいくことがなかったのです。思い立って実行したが・・はい。そこで思い立ってHA構成を組んでいこうと言うことでリソースを確保して実装しました。・・・が、早速初期化して間もないスタンバイノードのデータがPrimaryデータとして既存UTMに同期される始末・・・。一度は見事にUTMが全面初期化され、いろんな所に通信できなくなりました。3点ほど気をつければきちんと設定できることが分かりました。これを備忘録として記載しようと思います。VirtualNICの順とUTMが認識する順は異なるこれは、もしかしたらVXNET3を使用している時に限り発生するのかもしれません。言うのも、昔E1000として組んだ時はきちんと配列が対応できていたからです。VXNET3に切り替えて新規構築した時、ものの見事にNICの順序がずれてました。解決策としては、きちんとVM側のMACアドレスの対応付けを確認することです。画面にて、MACアドレスを確認することです。Standbyにする側は、「自動構成」にすることHAを構成する際、UTM9には3つの構成モードが存在します。OFF自動構成ホットスタンバイ実際には以下の通りであると理解しました。最初にやらかした失敗は、間違いなくこれが原因でした。両者ともに手動で設定するという意味合いに受け止めてアクティブ=パッシブモードにしていたのですが、何故かスプリットブレーンとなり、結果として初期化直後のスタンバイ機のConfigが正になってしまったのです。いうわけで、後で追加するノードは特に細かい設定は要らないので、かならずHAモード有効時は「自動構成」にしましょう。ライセンス含めて同期が行われるので、ぶっちゃけライセンスも要らないです。MACアドレスは使用できないこれが一番はまったポイントでした。MACアドレスを使用します。仮想NICのMACアドレスは、以下のような感じに定義されます。HA対象となるNICはeth0,1の2つです。eth2はHA通信用のポートになります。eth3は現状未使用です。■1号機のMACアドレスeth000:1a:8c:f0:40:e0eth100:1a:8c:f0:40:e1eth200:50:56:bf:e4:13eth300:50:56:bf:66:ed■2号機のMACアドレスeth000:1a:8c:f0:40:e0eth100:1a:8c:f0:40:e1eth200:50:56:bf:71:2deth300:50:56:bf:d6:77物理アプライアンスの場合、これで問題ありませんが、仮想環境の場合以下のような不具合が生じます。ESXi1にUTM1号機が存在するESXi2にUTM2号機が存在するUTM1号機がMasterノードであり、2号機はSlaveノードであるこのとき、実はESXi1号機に所属するVMしかUTMへアクセスできなくなります。いうのも、各ESXiのvSwitch上では双方に仮想MACアドレスが定義されています。そのアービトレーションは上位の物理スイッチ上で行われ、有効なインタフェースであるMaster側のポートがARPテーブルに登録されてます。以下は我が家のL3スイッチで確認されたARPテーブルの該当箇所です。dynamicESXi2に所属する側では、お隣のESXi1号機上にいるUTM9へ到達して欲しいと頃なんですが、自身のvSwitch上に存在するような形になります。そのためそこから本来のポートにたどり着けず、結果としてUTMに到達できなくなるようです。MACアドレスの使用を以下のコマンドにて禁じます。CLI必須で、root権限にてコマンド実行をする必要があります。0その後確認されたMACアドレスは以下の通りとなりました。■1号機のアドレスeth000:0c:29:5a:42:82eth100:50:56:a7:67:14eth200:50:56:bf:e4:13eth300:50:56:bf:66:ed■2号機のアドレスeth000:50:56:bf:30:31eth100:50:56:bf:04:13eth200:50:56:bf:e4:13eth300:50:56:bf:66:edスイッチ側も、Active側の仮想NICに割り当てられたMACアドレスが登録されています。dynamicMaster/Slaveの関係を確認できる各ノードの負荷状況HA化した状態の確認HA化すると、上記のようにGUIからどちらがMasterノードになるのか分かるようになっています。我が家ではプライマリノードを1号機に定めているので、フェイルオーバーした後にMasterノードが復帰すると自動的にフォールバックするようになっています。これとNginxが握っているリバースプロキシ部分を冗長化することで現在分散SNSをフル冗長構成にすることを考えています。本当はH2OというHTTPサーバを組み合わせてそれを実現できてた・・・はずなんですが、土壇場になってうまく外部からアクセスできず・・・こちらはこちらで記事作成途上で悩んでる最中なんですが、コツコツ組み立てていきたいと思います。実は、今月の中旬あたりに引っ越すことになりました。稼働後しばらく経過してからのクラスタ状況つい最近k3sに手を出し、しばらくMisskeyを動かしっぱなしにしてましたので、その稼働実績を採取しました。Bacula3.0.1-1(設定項目について考える)さー、インストールも終わったしバックアップだーと言いたいところだが、その前に、Baculaを自分なりに理解した結果を記載してみる。これまでは、CIFS接続を中心に扱ってきましたが、今回はNFS接続に挑みます。3560にてipv6を実装した。StoreOnce-CatalystタイトルとURLをコピーしました。