皆さんこんにちは、Red Hat の岡野です。
今回は、運用面から見たシステム稼働率の最大化と RHEL のパッチ適用について考えてみたいと思います。実は最近、セキュリティに対する意識の高まりを背景に、『RHEL のパッチ管理をやりたいんだけど』という問い合わせを沢山いただくようになりました。ただその一方で、既にサポート外となっている古いバージョンを継続利用していて不具合が発生し、表現はちょっとよくないですが、営業経由で『泣きの依頼』が来るようなことも、残念ながら発生しています。
そんな中、社内にあった古い資料の中にこんな文言を見つけました。
" 85% of critical issues raised to Red Hat support are already known to Red Hat or our partners "
サポートに来る重大なトラブルのうち85％は既知の問題。つまり、きちんと設定をし、パッチさえ当てていれば問題は起きなかった、ということです。これって結構重いメッセージですよね。
ちょうど RHEL 7 が来月、7月より ELS フェーズに入ります。システム更新に関して考える良い時期かなとも思いますので、そのあたりも含めて考えていただければと思います。
パッチ管理ベストプラクティス
一般的な RHEL のパッチ管理では、Red Hat が提供するリポジトリである CDN (Content Delivery Network) に接続し、必要なパッケージの入手やパッチの適用を行います。オンラインの場合は直接、オフラインの場合は CDN に接続可能な端末で入手し適用を行います。CDN の特徴として、提供されるパッケージは時とともにアップデートされていきます。
一方、システムの安定稼働の観点からは動作確認が取れた特定のバージョンで稼働させたい、というのが一般的かと思います。また、先ほどの『85％問題』を回避するには、特定のバージョンで動作テストを行った上で継続的にバージョンアップしていく必要があります。
このため、刻々と変化する CDN のある時点でのスナップショットを複数用意し、利用するリポジトリを柔軟に変更できるような機能が求められるのですが、これを実現するのが Red Hat Satellite です。
Red Hat Satellite を利用すると CDN からダウンロードしたパッケージの中から任意のバージョンのパッケージのみが含まれるカスタムリポジトリを作成し、コンテンツビューという形で提供することが可能となります。コンテンツビューは複数作成することが可能で、RHEL 単体やグループ単位でどのコンテンツビューを利用するかを柔軟に設定・変更することが可能です。例えば、以下の例では、App1、App2に対して本番環境とテスト環境を準備、そのそれぞれが、Satelliteから提供されている特定のパッケージを含むコンテンツビューを参照しています。
各システムがアクセス可能なパッケージは Satellite から変更しない限り同じものとなりますので確実に同一パッケージでの運用が可能となります。この機能を利用し、App1、App2をテスト環境を使って徹底的に動作確認を行い、問題ないことが確認出来たら本番環境をそちらに移行、つまり、Satellite 上でコンテンツビューの割り当てを変更し、本番環境のシステム更新を行う事が可能となります。
このコンテンツビューの作成とシステムへの割り当て作業を Ansible Automation Platform を使って自動化、サービス化するとさらに大きな効果をもたらします。・・・、と申しますのも、実は、RHEL のシステム更新が進まない大きな要因の一つに、
『アプリケーションが動かなくなると困るので、パッチ管理者側では勝手にシステム更新が行えない』
というものがあります。この理由、本当に多いのですが、Ansible Automation Platform を利用すると、どのバージョンをテスト環境及び本番環境で利用するか、さらにはパッチの適用自体をアプリケーション管理者側にオフロードすることが出来るようになります。アプリケーション責任者に各システムを稼働させるパッチレベルを決定させ、システムアップデートも実行させることが出来るということです。イメージは以下の通りです。
パッチ管理者は CDN で提供されるパッチ収集と時に発生するクリティカルなバグに対するHotFixの収集、そして、それらをコンテンツビューとして適切なタイミングで公開する作業に集中します。一方、アプリケーション管理者は各システムでどのバージョンを利用するかを決定します。実際の紐づけ作業には、Satellite と連携した Ansible Automation Platform を利用します。この紐づけの変更やパッチ適用を行う Playbook やジョブテンプレートはパッチ管理者が作成し、アプリケーション管理者はそれをサービスとして利用するイメージです。
アプリケーション管理者は各システムをテストするためのコードも開発します。さらには、このテストコードの実行も Ansible Automation Platform で自動化します。このテストコードを使ってテスト環境で徹底的に事前検証を行い、問題なければ本番環境に適用を考えるという具合です。また、万が一本番環境に適用した後、問題が発生した時のために、環境のバックアップとリストアの仕組みを、仮想環境やクラウド環境の管理者などに依頼してあらかじめAnsible Automation Platform のジョブテンプレートして作成してもらい、それを実際のパッチ適用のワークフローの中に組み込んでおくと、さらに安心して作業が可能となります。
まとめ
如何でしたでしょうか？触らぬ神にたたりなし。動いているものを触るのは怖い、というのはよくわかります。クリティカルなシステムであればなおさらです。しかしながら、重大障害の多くは既知のバグ。これを心にとめてシステムアップデート前提で仕組みを考えてみてください。このブログがその一助になれば幸いです。
RHEL の定期的なアップデートに関してはこちらもご参照ください。
bit.ly
