sidetech

(元)インフラエンジニアの寄り道メモ。

冗長可用性による複雑性

今、ホテルのチェックアウト1時間前ぐらいです。
これから長い帰国の旅です。

今回は不可抗力?な延長戦もあり、ちょっとしんどかったです。
Beforeaftercore
チラ見だけってことで・・・

だいぶ構成が違うぞ・・・みたいな。[E:coldsweats01]
10年前と今回・・・なのですが。

今回、過去にないぐらいカテゴリーの適用をしたのですが、これら全て関連していて、一部即興でやっている感じです。

昔はですね・・・遠隔地という事もあって、あえて冗長化というのを採用せずにコールドスタンバイの手段をとりました。
現地の人間がシンプルにトラブルに対応できると思ったのと、冗長構成による予期しない挙動の経験値がイマイチ足りなかったんですね・・・。

今回は、Meraki MXはActive/Passiveにして、コアスイッチは、2台追加して、3台のバーチャルシャシー構成に。
スイッチが1台壊れてもよいように、3台のうち1台は殆どスペアとして動いています。
これ以外にESXi構築してPOSTFIX構築してAD建てて、既存ADの修繕して、DNS作り直して、結構盛りだくさんにやりました。

取り組んでいる最中に断念したのはLACP(LAG)の設定ぐらいです。
一応、LAGの割り当てはしてあるのですが、使うのは辞めました。

とにかく可用性を上げる為に沢山のポートを消費し、判りやすくするために無駄にポートを消費させている部分もあり、メンテナンス性との兼ね合いで悩みました。

現地のIT管理者と話していて面白かったのは、中途半端に動いている事の方が調子が悪いという話でした。

例えば3台のVC構成でも、2台目が壊れたとすると、1台目と3台目は通信してしまっているので、何が原因なのかを判断するのに難しくなる・・・というものでした。
ナルホド成程なるほど。確かに一理あります。

なるべく、その負担も減るようにドキュメントにはどのポートが何に繋がっているかも記しているのですが、そうではなく、IT管理者が不在時にトラブルがあると、誰かしらに支援してもらわなければならない状況で、対応が難しくなる・・・というものでした。

私としては少しでもオンラインでいられるような構成や配慮を考えていたのですが、そうではないということです。(゜-゜)うーん。難しいですね。

まぁ、今回はサーバ関係の可用性は出来ていないので、ちょっとアンバランスなんですけどね…。

で、今回も例の監視で見ています。
Canadaeng
GMTの対応が出来るんで、こちらの時間でグラフが見られるよと言ったら喜ばれました。
ただ、VPN経由での監視なので、アラートはOFFにしておきました。これがちょっと課題なんだよねぇ・・・。そういえば夏時間対応されているのかな?!
とりあえず、ネットワーク機器だけ先行登録しときました。あとは帰国後で・・・[E:coldsweats01]

あと、現地の管理者に、私はGLOBALを含めて全部のインフラを見ているのか?と聞かれたので、YESと答えたら、「ビッグ・ブラザー」だなぁと言われました。
偉大な力で見守っているという意味らしいのですが・・・調べたらありました。。。たぶんこの架空の人物の事を指しているのだと思う。

https://ja.wikipedia.org/wiki/%E3%83%93%E3%83%83%E3%82%B0%E3%83%BB%E3%83%96%E3%83%A9%E3%82%B6%E3%83%BC

英語って難しいですね・・・。

さて、これから長いフライトにはいるのでここらへんで・・・。