実運用でつかんだ教訓
RHOSPの本番運用後、RHOSP上で動作するインスタンス数が増え、それに伴うパフォーマンス低下を抑制する目的で、フリービットではコンピュートノードの増強を図ってきた。
これは、CPUの使用率を低く抑える──つまりは、CPUに対するオーバーコミットを回避するための施策だ。ただ、この施策を進める中で顕在化してきたのが「メモリの逼迫」によってパフォーマンスが低下するという問題である。
「CPUのオーバーコミットを避ければ、メモリのオーバーコミットが起きても問題はないという考え方になりますが、実際にはその逆で、避けるべき部分はメモリのオーバーコミットです」(井口氏)。
Linuxは、メモリに余裕がある場合は積極的にファイルキャッシュでメモリを消費し、利用状況に応じてキャッシュを破棄する。ただ、ゲストOSとして稼動するLinux上のメモリ消費の内容はOpenStackのホスト側では把握することができないため、実際のメモリ消費用途によらずホストOSがスワップを使い始める場合がある。そのため、メモリ容量が十分に確保されていない環境では、パフォーマンスが低下してしまうのである。
この問題を解決するにはノードを一時的に停止させ、メモリを増設しなければならないが、それによってサービスを停止させるわけにはいかない。「そこで停止させるノードの仮想マシンをライブマイグレーションによって他ノードへ移動させる必要が生じたのですが、このマイグレーションが予約したとおりに実行されず、結局、レッドハットの技術サポートを仰ぐことになりました」と、井口氏は明かす。
レッドハットは、このライブマイグレーションの問題の原因がコンピュートノードを司るNovaコンポーネントにあることを突き止め、Novaのバージョンを更新して問題を解決したという。
挑戦は信頼の置けるパートナーとともに
「OpenStackのような先端技術によってドラスティックなITインフラの変革を成し遂げたいと考えるならば、ある程度の問題に直面することは覚悟しなければなりません。その覚悟がないなら、OpenStackによるIT革新はあきらめたほうがいい」と井口氏は言い切る。
確かに、挑戦/変革は問題発生のリスクを伴い、そのリスクをゼロにすることは不可能だ。ただ、たからこそ発生した問題にいかに迅速に、かつ的確に対処できるかどうかも重要となる。「そこでカギとなるのがディストリビューターのサポート能力です。その能力に優れたディストリビューターの支援がなければ、ユーザーが新技術による変革を推し進めることは難しく、我々がRHOSPを選択した大きな理由もそこにあります」と、井口氏は付け加える。
OpenStackの運用でトラブルに見舞われても、ユーザーがすべての問題を解決する必要はない。信頼できるパートナーが身近にいるのであれば、その力を借りるに越したことはない。そうしたパートナーとして、レッドハットは、OpenStackによるフリービットの挑戦と変革を支えている。