長年の経験で分かったExchangeの重大な不具合を防ぐ秘訣


(この記事は 2015 年 1 月 8 日に Office Blogs に投稿された記事 Concerning Trends Discovered During Several Critical Escalations の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

 

この数か月間、Exchange 2010 および Exchange 2013 に関するお客様からの重大なエスカレーション (業界で「CritSit」と呼ばれるもの) 数件に携わってきました。その結果、共通するいくつかの課題と傾向が浮き彫りになりました。今回のブログ記事では、こうした共通の問題について取り上げます。記事をお読みになれば、その大半は、事前に賢明な措置を講じることで防止できる問題だとご理解いただけるはずです。

ソフトウェアの修正プログラムの適用

圧倒的に件数が多かったのは、古くなったソフトウェアを実行しているという問題で、ほぼすべてのお客様に該当していました。これには、OS の修正プログラム、Exchange の修正プログラム、Outlook クライアントの修正プログラム、ドライバー、ファームウェアなどが含まれます。古いものを使用することは大きな問題ではないと思う方もいらっしゃるかもしれませんが、これに当てはまるお客様のほとんどが、最新のリリースでは解決されている既知の問題に悩まされていました。最新の状態を維持していれば、セキュリティに関する既知の不具合から環境を保護することもできます。また、古いバージョンのソフトウェアは、いずれサポート対象外となります (例: Exchange Server 2010 Service Pack 2)。

ソフトウェアの修正プログラムの適用は、マイクロソフトのソフトウェアのみにかかわる問題ではありません。相互依存するすべてのソリューション (Blackberry Enterprise Server、バックアップ ソフトウェアなど) を常に最新のリリースに更新することで、信頼性や互換性を最大限に高められるのです。

マイクロソフトでは、「すべてのソフトウェアを N N-1 ポリシーに準拠させる」というソフトウェア更新戦略を推奨しています。この「N」は Service Pack、更新プログラムのロールアップ、累積更新プログラム、メンテナンス リリースなど (ソフトウェア ベンダーによって使用される表現は異なります) の番号を表します。お客様におかれましても、ハードウェアのファームウェアやドライバーに同様の戦略を採用していただき、ネットワーク カード、BIOS、およびストレージ コントローラー/インターフェイスを常に最新の状態に更新されますことを強くお勧めします。

また、ソフトウェア ベンダーが規定するソフトウェア ライフサイクルに従って、特定のバージョンのサポートが間もなく終了する場合や、既にサポート対象外となっている場合には、ぜひサポート対象のバージョンへのアップグレードを適宜ご計画ください。

Exchange 2010 の場合、すべてのサーバーに Service Pack 3 と、ロールアップ 7 またはロールアップ 8 (この記事の執筆時点) を展開する必要があります。Exchange 2013 の場合、すべてのサーバーに累積更新プログラム 6 または累積更新プログラム 7 (この記事の執筆時点) を展開する必要があります。

Office 365 とのハイブリッド構成を採用している環境では、Office 365 との互換性を確実に維持するために、ハイブリッド構成に含まれるサーバーで必ず最新のバージョン (例: Exchange 2010 SP3 RU8 または Exchange 2013 CU7) または 1 つ前のバージョン (例: Exchange 2010 SP3 RU7 または Exchange 2013 CU6) を実行する必要があります。ハイブリッド展開では依存関係の要件も存在するため、ハイブリッド構成を使用する場合には、ソフトウェアを常に最新の状態に更新することがさらに重要となります。

変更管理

変更管理は、環境の正常性を維持するために必要不可欠なプロセスです。変更管理を行うことにより、変更の提案を特定、承認、却下するプロセスを構築できます。また、これまでに発生した変更の履歴を確認することも可能になります。しかし、高額のコストが発生する場合にのみ変更管理プロセスを活用し、単純な変更と見なされる場合には変更管理プロセスを省略するケースが多く見られます。

変更管理プロセスの構築に加えて、運用環境を可能な限り反映させたテスト環境で、提案されている変更をすべて検証することも重要です。サードパーティ製のアプリケーションを連携させているのであれば、それもテスト環境に含める必要があります (Exchange を更新した際に、連携するアプリが動作しないという報告を受けるとは決して少なくありません)。

テスト環境は、提案された変更の機能性を検証するために非常に有効ですが、多くの場合、スケーラビリティに関する影響については確認できません。この問題に対処する方法の 1 つとして、「運用環境の分割 (slice in production)」が挙げられます。これは、一部のユーザーのみに変更を展開する方法です。この一部のユーザーは、テクノロジに応じて異なる手段 (専用のフォレスト、専用のハードウェアなど) を利用して、他のユーザーから分離することができます。Office 365 では、多種多様な方法で運用環境の分割を利用しています。たとえば、新機能の一般リリースに先立って一部のお客様にテスト (社内の用語では「ドッグフード」) していただいたり、全世界への展開前に先行リリースとして新機能をご利用いただいたりしています。

スケーラビリティの影響をテストする環境を構築できない場合は、少なくとも使用しているすべてのコンポーネントを含む環境を構築し、常に最新の状態に更新することで、主要な活用シナリオにおいて変更を検証できるようにします。

このほか、共通する課題としては、複数の変更が 1 つの変更管理要求にまとめられてしまっていることも挙げられます。複数の変更をまとめることに差し障りはないように思われるかもしれませんが、トラブルシューティングを実施する際には、複数の変更を行うことは絶対に避けなければなりません。まず、問題を解決できても、どの変更によって問題が解決したのかを特定できません。また、複数の変更によって現在の問題が悪化する可能性も十分にあります。

複雑性

障害は必ず発生するものです。どんなテクノロジを駆使しても、この事実を覆すことはできません。ディスク、サーバー、ラック、ネットワーク機器、ケーブル、変電設備、ポンプ、発電機、オペレーティング システム、アプリケーション、ドライバー、およびその他のサービスなど、IT 関連のサービスや製品において、障害の影響を受けることがない要素は間違いなく存在しません。

そのため、マイクロソフトでは、障害の発生を抑えるために冗長性を組み込むという方法を採用しています。これは、1 つのエンティティで障害が発生する可能性が高い場合に複数のエンティティを使用する方法で、Web サーバー アレイ、ディスク アレイ、フロントエンドおよびバックエンド プールなどで採用されています。ただし、冗長化は非常にコストがかかります (単純な比例関係でコストが増加します)。たとえば、2007 のリリースまで Exchange の中核を成していた SAN ベースのストレージ システムは、コストの負担が大きく複雑でもありました。そのため、Exchange チームではストレージの重要な要素が直接アーキテクチャに組み込まれるように Exchange を強化することになりました。SAN のシステムやディスクでも例外なく障害が発生するでしょうし、SAN のテクノロジを使用した冗長性の高いシステムの実装には多大なコストがかかります。Exchange が強化されたことで、高コストかつスケールアップ方式の高パフォーマンス ストレージ システムが不要になりました。現在では、ごく一般的なディスク コントローラーを使用した JBOD 構成で、一般的な低パフォーマンス SAS/SATA ドライブを搭載した一般的なスケールアウト方式のサーバー上で実行できるように最適化されています。このアーキテクチャにより、あらゆるストレージの障害から Exchange を回復できるようになりました。

Exchange にレプリケーション アーキテクチャを構築し、ごく一般的なハードウェアに対して Exchange を最適化すると、ハードウェアの視点から、発生する障害モードが予測可能になります。しかも、他のハードウェア レイヤーから冗長性を排除することができます。NIC や電源装置などの冗長コンポーネントをサーバー ハードウェアから取り除くことも可能です。ディスク、コントローラー、マザーボードのいずれかで障害が発生しても、最終的に他のデータベース コピーが別のサーバー上でアクティブ化され、同じ結果になります。

ハードウェアまたはソフトウェアのアーキテクチャが複雑になればなるほど、障害イベントの予測は困難になります。しかし、大規模な障害管理を行うには、復旧を予測可能にしなくてはなりません。そのためには、障害モードを予測できる必要があります。複雑な冗長化の例としては、アクティブ/パッシブのネットワーク機器のペア、複雑なルーティング構成を使用したネットワーク上の集約ポイント、ネットワーク チーミング、RAID、複数のファイバー配線などが挙げられます。

複雑な冗長性の解消と言ってもイメージしにくいと思いますが、ハードウェアの冗長性をなくして可用性を向上できる方法として、複雑な冗長モデルからソフトウェアベースの冗長モデルに移行し、予測可能な障害モードを作成する方法があります。

これまでに対応した複数の CritSit のエスカレーションの中には、複雑なアーキテクチャに含まれるコンポーネントが、解決しようとしているシステム問題の一部となっているケースが見られました。

  1. Exchange 2013 でラウンド ロビン接続管理または最小接続管理を使用するようにロード バランサーが設定されていない。お客様は、最小接続管理を実装しておらず、「スロー スタート」機能を有効にしていませんでした。スロー スタート機能を使用すると、サーバーが負荷分散プールに戻されたときに、すぐに接続が殺到することがなくなります。その代わりに、そのサーバーへの接続が徐々に増加します。ロード バランサーに最小接続管理のスロー スタート機能が備わっていない場合は、ラウンド ロビン接続管理を使用することを強くお勧めします。
  2. 多数のソケットまたは物理 CPU を搭載したマシンに関するベンダーの推奨事項に従ってハイパーバイザー ホストが構成されていない。
  3. Exchange サーバー、Active Directory サーバー、Lync サーバーとの間にファイアウォールが設定されている。Exchange、ファイアウォール、およびサポート (英語) に関する記事で説明されているように、Exchange サーバーに他の Exchange サーバー、Active Directory サーバー、Lync サーバーとの通信を妨げるネットワーク ポートの制限がある構成をマイクロソフトではサポートしていません。
  4. 適切なファイルベースのウイルス対策除外リストが用意されていない。
  5. 「フェールオーバー データセンター」に非対称設計を採用している。すべての事例において、フェールオーバー データセンターのサーバー数はプライマリ データセンターよりも少ない状況でした。これらのアーキテクチャの設計が、フェールオーバー データセンターはメンテナンスや重大な障害発生時にのみ使用されるという論理に基づいていたからです。この論理の根本的な欠陥は、ユーザー アクティビティが 100% になることはないと想定している点です。その結果、フェールオーバー データセンターがアクティブ化された場合に、応答までの待機時間の延長、メール配信の遅延などのパフォーマンスの問題が発生し、ユーザーに影響を与えることになります。
  6. マイクロソフトのガイダンスに従って SSL オフロード (サポートされてはいますが、めったに推奨されないシナリオです) を設定していない。
  7. メッセージング環境をサポートするために必要な容量および I/O の要件を満たすように記憶域ネットワークが設計されていない。Exchange や他のアプリケーションをサポートするために、階層型記憶域への投資を行うお客様もいらっしゃいます。しかし、Extensible Storage Engine および Managed Store の動作や、送信される要求のランダムな性質が原因となり、階層型記憶域の有効性が Exchange では発揮されません。必要なときに十分な I/O を得ることができないためです。

では、複雑さを解消するにはどうすればよいでしょうか。Exchange の場合、予測可能な復旧モデル (データベース コピーのアクティブ化など) を使用しています。マイクロソフト推奨のアーキテクチャは、複雑さを軽減し、対称的な設計を実現することで、障害が発生した場合にもユーザー エクスペリエンスを維持できるように設計されています。

推奨事項の無視

もう 1 点、懸念すべき傾向として気付いたのは、製品ベンダーからの推奨事項が繰り返し無視されているということでした。製品の構成または管理に関するベンダーのアドバイスが無視された理由を数多く聞いてきましたが、お客様がベンダーよりもベンダーの製品について熟知しているケースはほとんど皆無です。ベンダーから「X を構成してください」あるいは「バージョン Y にアップデートしてください」といった推奨事項が提示された場合、正当な理由がある可能性が高いため、そのアドバイスには従ったほうが賢明です。

マイクロソフトの推奨事項は、蓄積されたデータに基づくものです。電話でのサポートやリスク評価を通じて収集されたデータや、お客様から得られたデータなどといったデータをくまなく分析して、推奨事項を作り上げています。多数のお客様にご利用いただいているからこそ、こうして明らかになったことの積み重ねが非常に重要な役割を果たしているのです。

展開に関するベスト プラクティス

Exchange でも他の製品でも、新しいバージョンのソフトウェアを展開する際には、適切な導入計画に従うことが重要です。導入計画に従えば、展開中に予期しない問題が発生するという不要なリスクを冒すこともなくなります。

Exchange の展開において、適切な計画は欠かせません。導入計画には、少なくとも以下の手順を含める必要があります。

  1. 解決する必要のあるビジネス要件および技術要件を特定します。
  2. 使用のピーク時を把握し、ピーク時中の I/O およびメッセージ プロファイル データを収集します。
  3. 収集した要件およびデータに基づいてソリューションを設計します。
  4. Exchange Server のロール要件計算ツール (英語) を使用して、収集したデータに基づく設計と、設計に必要となると推定される要素をモデル化します。
  5. 計算ツールの出力、設計の選択、ハードウェア ベンダーのアドバイスに基づいて必要なハードウェアを調達します。
  6. 設計に従ってハードウェアを構成します。
  7. 運用環境での使用を開始する前に、(Jetstress 利用ガイド (英語) の推奨事項に従って) Jetstress (英語) を使用してストレージ システムを検証し、ストレージ構成が計算ツールで定義した要件を満たすことを確認します。
  8. ハードウェアの検証が完了したら、想定される運用環境の負荷を反映したパイロット環境を展開します。
  9. パフォーマンス データを収集して分析します。実際のデータが理論的な予測と一致することを確認します。ユーザー数の要件を満たすためにパイロット環境にハードウェアを追加する必要がある場合は、必要に応じて設計を最適化します。
  10. 最適化した設計を展開し、残りのユーザーへの導入を開始します。
  11. 引き続きデータの収集と分析を行い、変更が発生した場合には調整を行います。

ここで重要なのは、最後の手順です。アーキテクチャを導入した後、「なぜシステムにオーバーロードが発生しているのか」と疑問に思われるお客様は実に多くいらっしゃるのですが、状況とは変化し続けているものです。数年前には、個人所有デバイスの業務利用 (BYOD) を許可している企業は多くありませんでしたが、現在では常識となりつつあります。その結果として、メッセージ環境も絶えず変化しており、ユーザーもメールボックス容量の増加、デバイスの多様化、デバイスの新機能など、さまざまな変化に適応しています。これらの変化は設計にも影響を及ぼし、より多くのリソースを消費する可能性があります。これに対応するためには、システムのパフォーマンスの基準化、監視、評価を行い、適宜変更を加える必要があるのです。

履歴データ

規模を問わずに正常なサービスを実行するには、ソリューションを監視し、問題が発生したときにリアルタイムで特定するだけでなく、ユーザー数やユーザー アクティビティの成長を事前に予測して、傾向を把握しておく必要があります。パフォーマンス、イベント ログ、プロトコル ログの各種データは、次の 2 つの重要な役割を果たします。

  1. 時間の経過に伴うユーザーのメッセージ プロファイルの増加について、傾向の把握および判断を行うことができる。
  2. 問題が発生した場合に、過去のデータをさかのぼり、見逃した指標がないかどうかを確認できる。

収集したデータは、環境全体の正常性を示す高度なレポートを作成するためにも使用できます。それらのレポートを毎月のサービス レビュー時に共有することで、正常性や指標、先月実施された対策、来月の計画、環境内で発生している問題、問題を解決するための手順などの概要を把握することができます。

履歴データを収集および保存する監視ソリューションを構築していない場合でも、必要なデータを収集することは可能です。

       Exchange 2013 では、パフォーマンス データを自動的に取得し、Microsoft\Exchange Server \V15\Logging\Diagnostics\DailyPerformanceLogs フォルダーに保存します。Exchange 2013 を実行していない場合は、Experfwiz (英語) を使用してデータを取得できます。

       イベント ログには、Exchange によってネイティブで記述される関連イベントがすべて記録されます。残念なことに、多くのお客様は短期間 (1 日) でイベント ログをフラッシュするように設定していらっしゃいます。最低でも 1 週間は情報を収集し、保持するようにしてください。

       Exchange では、ユーザーおよび各自のデバイスの動作について、大量の有用な情報がプロトコル ログに自動的に記録されます。Log Parser Studio 2.2 を使用すれば、このデータを簡単に利用することができます。

       メッセージ追跡データはハブ トランスポート サーバーまたはメールボックス サーバーに保存され、環境内のメッセージ フローに関する豊富な情報を確認できます。

まとめ

この記事の最初に述べたように、ご紹介した問題の大半は、事前に賢明な措置を講じていただくことによって防止できます。今回の記事がきっかけとなって、皆様の環境でもこうした問題を抱えていないか調査し、問題を解決するための対策を立てて、CritSit のエスカレーションを回避していただければ幸いです。

Ross Smith IV
Office 365 カスタマー エクスペリエンス担当
主任プログラム マネージャー

Skip to main content