about networking, music, motorbike and some stuff…

またまただいぶ間が空きました。XenServerも5.5のアップデータが最近出てきましたね。
色々ネタは溜め込んでいてdraftなものが多々あるのですが、XenServerを本格稼働する(or している)ユーザには知っておいてほしいネタって事で記載します。最近使用しているサーバは大抵Dellだったりするのですが、DellのオンボードなNICはBroadcomなんですよね。自宅で遊ぶ程度だったらNICもRealtekだったり、入手性からIntelだったりで問題ないのですが、BroadcomのNICでXenServerを使用しようとしている人は要注意です。

先に何が起こるかというと、bnx2のドライバの問題によりjumbo frameの設定をしているNICがBroadcom製の場合、ifup/ifdownやrmmodでkernel panicが発生しXenServerホストの再起動が発生します。Redhat ELにも存在しているバグのようです。
仮想化していない状態であれば、1台のサーバが落ちる程度(というカジュアルな場合だけでもないのですが)ですし、ifup/ifdown/rmmodなどは大抵行われないオペレーションなのでそれほど目立った問題にはなっていないようです。

ところが、XenServerでは話が全く変わってきます。
XenServerは複数の物理サーバを「リソースプール」として纏める機能があるのですが、これが問題になります。XenServerはXapiというapiで複数の物理サーバを纏めて管理する事ができます。物理サーバの中で1台が「プールマスタ」として全ての物理サーバに対してのオペレーションを引き受けるapiを提供するのですが、プールマスタといえども所詮は Linux。メンテナンスで再起動の必要も出てきます。その際にはプールマスタとしての役割を別の物理サーバへ移す訳ですが、管理上の制約なのかこの時インターフェースの再設定が全ての物理サーバで行われます。そこでifdown/ifupなどのコマンドが使用され、kernel panicを起こすのです。かといって、リソースプール内でiscsiのストレージを使用するとなると、jumbo frameは必須で気軽にはずすわけにも行きません。
わかりにくいかもしれませんが、纏めると以下の2点の現象が発生します。。

1. bnx2なXenServer5.5ではifdown/ifup/rmmodなどの操作でkernel panicが発生、再起動が発生する
2. XenServerは物理サーバを纏めて管理する「リソースプール」という機能があり、「プールマスタ」の変更では全ての物理サーバに置いてネットワークインターフェースの再起動が発生する

に集約されます。勘の良い人はお分かりかもしれませんが、この２点から以下のような事象が発生するわけです。

セキュリティアップデート等でプールマスタの変更を行うと、リソースプール内のBroadcom製のNICを使用しているサーバが全てkernel panicを起こし、再起動する。

10台の物理サーバで各サーバに5台の仮想サーバを稼働させていたとすると、同時に50台の(仮想)サーバが落ちるって事です。幸い該当のプール上の仮想サーバは開発用だったりで、甚大な被害はありませんでしたが、サーバ管理者からするとクラウドなんて糞食らえって事になりますよね。該当してしまった不幸な管理者の方、どうしたらいいのって話に鳴ると思うのですが、Linuxベースのプロダクトということで、ドライバを更新すれば解決できます。サポートの問題は残りますが、解決方法をCitrixのフォーラムにポストしました。

つか、Citrix開催のXenServerのセミナーでエンジニアの人にこの件で話をしたんですが問題の重大性を理解してもらえず、「そんなの知らない、情報が欲しければサポート契約してね」みたいな感じで、問題意識の共有ができなかったのが残念です。ヘビーユースの予定だったのでサポート契約もかなり前向きに検討していたのですが、一気にモチベーション下がりました。

という残念な〆ですみません。まとめると、broadcomなNICをXenServerで使用するときはXenServer付属のドライバではなく、Broadcom製や各ベンダー配布のドライバに更新してから使えってことです。ちなみに、XenServer5.5 update1でもこの問題は解決していないので、update1インストール後もドライバの更新が必要になります。