Microsoft が実践する Exchange Server の高可用性を実現する方法
Microsoft IT は、Microsoft Windows Server 2003 クラスタで Microsoft Exchange Server 2003 を使用するだけでなく、サーバーとストレージの最新ハードウェア製品を使用して、メールボックスの可用性を 99.99% に高めるいう目標を設定しました。この目標を達成するために、厳格なサービス レベル契約 (SLA) と定期的なレビュー プロセスを導入し、この積極的な目標に向かって進みます。目標を達成できなかった場合は、その時期と理由を把握します。
Microsoft の従業員は、"Microsoft は電子メールで運営されている"、とよく言います。Microsoft 従業員の標準的なメールボックスは、200 MB のサイズがあります。Microsoft では、平均して、毎営業日に 300 万件のメッセージが社内で送信され、1,000 万件のメッセージ (スパムやウイルスなど、未承諾の電子メール メッセージを含みます) が社外から送信されます。Microsoft において、電子メールは共同作業や知識共有に不可欠なツールです。
Microsoft Information Technology (IT) グループは、電子メールが Microsoft 従業員の生産性や創造性に重要であることを認識しているため、"99.99%" の可用性を達成するという目標を設定しました。つまり、すべての Exchange メールボックス サーバーが、99.99% の時間、稼動状態を保つということです。これは、1 年間に許容されるメールボックスごとのダウンタイムが 1 時間未満であることを意味します。
Microsoft には可用性について複数の計測項目がありますが、基本の計測項目はメールボックス サーバーの可用性です。このドキュメントを執筆している時点で、Microsoft では、前四半期の 6 週間でメールボックス サーバーの可用性が 99.99% を超え、毎週の可用性は平均 99.97% でした。
メモ このドキュメントの統計情報と計測方法は、社内の会計年度 2005 (FY05) の第 1 四半期のレポートから引用したものです。概して、昨年 Exchange の可用性を計測した結果も、ここで紹介する結果と同様の内容となっています。
ここでは、Microsoft における Exchange の可用性を計測する方法について説明し、可用性を高めるために Microsoft が導入したプロセスを概説します。ただし、このドキュメントは、操作を説明することを目的とするものではありません。また、Microsoft でメッセージング インフラストラクチャを運用する方法を、大まかなレベルであっても、他の企業にそのまま適用できる可能性はあまりありません。ただし、Microsoft IT が開発した指針や理念は、ほぼすべての環境に適用できます。これは、Exchange だけでなく、他のテクノロジにも適用できます。
Microsoft IT が学んだ最高レベルの教訓は、次のとおりです。
| • | 弁解しないこと Microsoft IT にとって、だれの過失であろうと関係なく、Exchange サービスの中断は Exchange の可用性の低下を意味します。ダウンタイムが、計画的であっても予定外であっても、Exchange やネットワークの問題が原因の場合でも、またはハードウェアの破損や自然災害が原因でも、すべて SLA に反するものと見なされます。Microsoft IT が電子メール サービスの品質に影響を及ぼす問題を解決するうえで、この姿勢は重要です。 |
| • | パフォーマンスの計測とレビュー 計測を設定したり計測を行ったりするだけでは不十分です。実際のパフォーマンスを許容範囲内に保つには、各計測を管理により定期的にレビューし、行動に移す必要があります。Microsoft IT は、毎週、サービス レビュー会議を開いています。この会議では、関係者がその週のスコアカードを確認し、計測ごとに逸脱している部分を解析し、改善します。効果を上げるには、レビューは毎月ではなく毎週行う必要があります。高可用性を達成するには、定期的なレビューを重視することが重要です。SLA の定義は簡単ですが、成功と失敗を定期的に分析するために必要な規律を維持することは困難です。 |
次の節では、Microsoft が適切な計測方法とサービス レベル契約 (SLA) を採用した方法について説明します。続いて、高可用性を維持するために必要であるため重要視している、現在進行中の 4 つの分野について説明します。
トピック
 | Microsoft による Exchange の可用性の計測方法 |
| 可用性の実現と維持 |
| まとめ |
| 詳細情報 |
Microsoft による Exchange の可用性の計測方法
Microsoft IT では、Microsoft Exchange Server 5.5 で社内の電子メール システムを実行するようになってから、理念が根本的に変わりました。それ以前、メッセージング チームは、自分たちの任務は Exchange サーバーの稼動状態を保つことであると考えていました。ネットワークが停止した場合、それは Exchange の問題ではありませんでした。ネットワークが利用できなくても、Exchange は稼動していたためです。オペレーティング システムの更新プログラムをインストールするためにダウンタイムが予定された場合も、Exchange の問題ではありませんでした。
Microsoft で Microsoft Exchange 2000 Server を導入したことが、このような姿勢が変化する大きな要因となりました。Exchange 2000 は Active Directory® ディレクトリ サービスと緊密に統合されたため、Active Directory の問題は、メッセージング チームの支援なしで解決される他人事として無視できなくなりました。Active Directory チームから見ると、Exchange は、ディレクトリ サービスを単体で最大に消費するものなりました。また、Exchange による負荷を処理するには、Active Directory を正しく設計する必要が生じました。
Microsoft で Active Directory が展開されたため、Exchange と Active Directory の両チームは、隣り合った席に移動しました。問題を解決し、設計について議論するために、両チームは毎週会議を開きました。この協力関係が成功したおかげでメッセージング チームの視野が広がり、Exchange の管理だけでなく、Exchange の動作に影響を及ぼすすべてのものに信頼性を確保することに責任を持つようになりました。
現在、メッセージング チームは、Exchange サーバーだけでなく、Exchange サービスという点で責任を担っていると考えています。Microsoft IT のメッセージング チームのディレクターである Chris Nelson は、"現在では、自分たちが所有していないものも所有している" と表現しています。ここから、可用性を計測するときに弁解しない、という理念が導き出されました。
弁解しないこと
多くの場合、企業の SLA では計画的なダウンタイムと予定外のダウンタイムを区別しています。また、営業時間に発生したダウンタイムのみをカウントしています。Microsoft IT では、クライアントが自分の電子メール データベースに接続やアクセスができない場合、すべてをカウントに入れます。このとき、理由や発生時間は考慮せず、またピーク時とオフピーク時への重み付けもしません。また、ダウンタイムが Exchange の問題に起因するのか、または Exchange の動作に影響を及ぼすインフラストラクチャに起因するのかについても、関係ありません。他のサービスで新しいセキュリティ更新プログラムをインストールするためにダウンタイムが発生する場合、その中断時間は、メッセージング チームの可用性目標に対して不利にカウントされます。
最近、大規模の外注を行った地方のデータ センターは、台風のために週末は完全に機能が停止しました。データ センターが浸水したため、Exchange サーバーも停止しました。この事故は、Exchange が原因で発生したものでないことは明白ですが、世界全体での Exchange 可用性の低下としてカウントされました。
Microsoft IT のメッセージング チームがこのような停止にまで責任を担うと、弁解しないというポリシーが極端に解釈されるのではないかと思われるかもしれません。メッセージング チームが熱帯性低気圧や街全体の停電にまで責任を担うことが公平であるとはたしてだれが思うでしょうか。
重要なことは、このアプローチによって、チームが問題に対処する方法が変わるということです。メッセージング チームは、所有するサーバーの稼動状態を保つだけでなく、Exchange に影響を及ぼすインフラストラクチャの監視や理解、(必要であれば) 変更にも責任を感じています。Microsoft IT では、Exchange の停止は決して他人事ではないのです。メッセージング チームは、場所にかかわらず、WAN 経由のクラスタ サーバーから各クライアントまで、すべての経路で Exchange システムを信頼できるように、真面目に、そして容赦なく取り組んでいます。
台風によるデータ センターの停止によって、複数の SLA 計測にわたり、数千分もの稼動率が失われました。メッセージング チームは、この停止を他人の過失ではなく、自分たちの問題として扱いました。災害が発生したとき、消極的に復旧を待つのではなく、サービスを早急に復元するために、指導したり、創造的なアイデアを出したりしました。災害後、メッセージング チームは、そのデータ センターのプロセスや機能を改善する調査を開始しました。そのデータ センターは、同様の災害を十分に防ぐように改善できないことが判明すると、メッセージング チームは、データ センターのサーバーを頑丈な施設に移動することを決定しました。障害が発生したデータ センターは、2004 年末までに完全に廃止される予定です。また、このデータ センターの機能は、高度な保護が可能な場所にあり、全体的に高機能なデータ センターに移動されています。
メッセージング チームは、原因にかかわらず停止のすべてに責任を持つ一方で、それぞれの停止について根本的な原因も追跡します。この情報は、トラブルシューティングと傾向対策の場合にも貴重な情報となります。また、他のチームやベンダに変更を依頼する場合や、Exchange サービスの可用性の改善に必要なリソースや変更の正当性を示す場合に必要となる、客観的な支援にもなります。
Microsoft では、Exchange のダウンタイムの多くは Exchange と関係がありません。Microsoft が、リリース前のテスト バージョンの Exchange Server ソフトウェアと共に、常に多数のサーバーを実行していることを考えれば、これは注目に値することです。ここ数か月にわたって、Exchange の総合ダウンタイムのうち 7% は、計画されていた Exchange アップグレードのためでした。Exchange ダウンタイムの 6% は、Exchange 固有のその他の問題によるものでした。残る "87%" のダウンタイムは、Exchange 以外の問題によって発生しました。
最近発生した Exchange のダウンタイムの多くについて、次の 3 つの主要原因があります。
| • | ストレージの問題 |
| • | データ センターの完全な停止 |
| • | Exchange 以外のソフトウェアのインストールとファームウェアの更新 |
現在、メッセージング チームは、主要なストレージ ベンダと継続的に連携して、製品に改善を加えたり、各ベンダのプラットフォームにおける Exchange のベスト プラクティスを定義しています。データ センターは、停止に対応して改造または移設が行われました。また、メッセージング チームは、Windows Server 製品の開発チームや他のベンダと効率的に連携し、ソフトウェアの更新による再起動の要件を緩和し、頻度を減少させてきました。以上のことはいずれも、メッセージング チームがすべての問題を自身の責任として扱ったことで実現されました。
適切な計測と SLA の定義
Exchange が稼動しているとは、正確には何を意味するでしょうか。あるサーバーから別のサーバーに、電子メール メッセージを配信するのに 1 時間かかった場合、このシステムが稼動状態にあったと見なされるでしょうか。データベースはマウントされて使用可能ですが、クライアントからはアクセスできない場合はどうでしょうか。また、クライアントは電子メール メッセージを送信できますが、受信できない場合はどうでしょうか。サービス可用性の計測は、クライアントがメールボックスにアクセスできるかどうかだけでなく、サービスのパフォーマンスも考慮に入れる必要があります。また、計測を行うことが重荷になったり、広すぎる意味を持たないように、適切な細かさに設定する必要もあります。
メールボックス サーバーの可用性を計測する場合、ダウンタイムを計算する明確な方法として、メールボックス時間 (分数) が挙げられます。対象となる各サーバーやデータベース上のメールボックス数を加算して、その数を、予測される可用性の分数で乗算します。必要に応じて、各メールボックスのダウンタイムを減算します。または、より単純に、ダウンタイムは、期間ごとのサーバー時間 (分数) でレポートするという方法もあります。Microsoft IT では、"データベース時間 (分数)" で計測しています。つまり、各データベースを使用できない時間 (単位 : 分) を基準にしています。これは、メールボックス時間による計測は、必要以上に複雑であり、サーバー時間による計測では他のサーバー負荷や停止の条件が計算に入っていないためです。たとえば、あるサーバーのデータベースが 1 つだけ停止して、他のデータベースはすべて実行されている場合などが挙げられます。
一般的な Microsoft IT の Exchange メールボックス サーバーは 20 のデータベースを管理しています。このサーバーが停止した場合、1 分に付き 20 データベース時間と計算されます。99.99% の可用性を維持するためには、Microsoft のメールボックス サーバー全体で、1 週間にわずか 623 データベース時間のダウンタイムが許されるだけです。メッセージング チームがやむを得ず 1 つのメールボックス サーバーを 30 分以上停止するだけで、その週全体としての可用性が "99.99%" になってしまいます。これで、99.99% という稼動率の目標がいかに厳格なものかおわかりいただけたと思います。この目標を頻繁に、またはときどき上回ることでも (大幅に下回ることがなければ)、大きな成功と言えます。
メモ Microsoft では、Exchange Server 2003 メールボックスのクラスタ化された各仮想サーバーで、20 のデータベースを管理しています。これは、1 つの Exchange サーバーや仮想サーバーで対応可能な最大数です。一般的な Microsoft IT の各 Exchange データベースは、200 のメールボックスを保持しています。したがって、最大数のデータベースを管理する Microsoft の Exchange サーバーの場合、約 4,000 のメールボックスを管理しています。地域によって、サーバーの管理するデータベース数やユーザー数は少ない場合もありますが、1 データベースのダウンタイム時間は、一般に、約 200 分のエンド ユーザー ダウンタイムに相当すると考えられます。ただし、ユーザーごとのダウンタイムは直接計測されません。メールボックスが 200 未満であるデータベースでは、実際のメールボックス時間ではなく Microsoft IT で実施しているデータベース時間による計測を行うと、停止の影響が実際よりも大きく示される場合があります。
大規模な Exchange システムでは、複数のサービスと機能が複雑に混在しています。稼動率の計測を適切に定義して、実際のビジネス要件に対応することが重要です。SLA の計画は慎重に行い、その達成に必要な実費用を考慮します。計画が不十分な SLA では、次に示す例のように、不合理な結論にたどり着きます。
不適切な予測による不適切な費用
ある大規模な Exchange のエンタープライズ インストールにおいて、世界全体で、イントラ ネットワークのすべての電子メールを必ず 5 分未満で 100% 配信する、という SLA が定義されました。当時、この SLA は容易に 99.99% にまで達しました。100% にならなかったのは、ある会社で送信された 1 か月に 1 つの電子メールのためです。このように例外的なメッセージを受信するには、世界中のどのメールボックスでも 8 分近くかかりました。この予測可能な遅延によって実務に及ぼした影響はありませんでしたが、SLA には違反しています。
この問題に対処するため、その他のユーザー要求は適切に処理していたネットワーク リンクがアップグレードされ、多大な費用がかかりました。配布グループと配布グループの拡張サーバーが再構築されました。この変更で、最大配信時間が短縮されたため、平均の配信時間も短縮されました。古いディスク システムの置き換えや、メールボックス サーバーのパフォーマンスの改善に使用できたはずの資金は、たった 1 つの電子メールがすべての宛先に迅速に配信されるためだけに注入されました。
Microsoft 社内の電子メール配信 SLA は、この例で示した SLA よりも厳格でありながら、寛大でもあります。Microsoft の SLA では、電子メール メッセージが迅速に届くことをユーザーが期待していると認識していますが、その期待を決して裏切らないためにネットワークを過剰に構築することは求めていません。
Microsoft では、microsoft.com の電子メール アドレス間で送信される電子メール メッセージについて、宛先が世界のどこであっても、99% が 90 秒以内に到達する必要があります。この SLA は社外アドレスへの配信には適用されません。社外の場合、このような SLA は正確に計測できず、また Microsoft IT が改善や制御するのは不適切なためです。
SLA が不十分なため効果が低下する
皮肉なことに、前述した大規模な Exchange のエンタープライズ インストールには、古い電子メールの保存や復元に対処する SLA がありませんでした。このため、バックアップと復元に失敗しても、SLA 違反ではありませんでした。したがって、すぐには管理上の注意点となりませんでした。IT 部門は、災害から復旧する方法として、古いデータの復元にはほとんど労力をかけず、新しいデータベースから開始することに慣れてしまいました。重役のメールボックスを管理する重要なサーバーに影響が及ぶに至ってようやくこの問題が認知され、対処されました。
この話のように、SLA が不十分であったり欠けている点があったりする場合でも、無害とは言えません。不適切な SLA により、少ないリソースを優先度が高いことに回さなかったり、専門家がささいなことを重視したりする結果になる場合があります。計測と SLA を定義する場合、その目標に責任を持つ、すべての運用チームが参加することが重要です。協力やフィードバックがない状態で厳格な SLA や計測が課せられると、予期しない結果に結び付いたり、重要な問題の見過ごしや隠匿が生じる原因となります。
意義のある SLA を作成するためのガイドライン
Microsoft IT は、SLA と稼動率の計測方法を作成するときに、次の点を考慮しました。他の企業でも同様に検討する場合を考えて、推奨事項を添えます。
| • | ビジネス要件 高可用性を実現する費用は、利点とつりあわない可能性があります。目標を設定する前に、組織で実際に必要な可用性を解析します。 |
| • | 適度な細かさ Exchange システムには、可用性に複数の計測方法があり、稼動やダウンの計測は 1 つだけではありません。システムに異なる部分があれば、要件も異なります。たとえば、他のサーバーにデータがレプリケートされているパブリック フォルダ サーバーの場合、最高経営責任者のメールボックスを管理するメールボックス サーバーと同程度の可用性は必要ありません。 |
| • | 責任 個人またはチームは、自身の計測に責任を持つ必要があります。また、その個人やチームが、計測に影響するシステムを制御するための適切な権限を確実に持つようにする必要があります。 |
| • | 通常のリスクと特別なリスク ネットワーク停止と停電のほかに、ディスクやサーバーの障害も通常のリスクであり、予測可能です。発生は予測できるため、予測される事象として計画する必要があります。通常のリスクを考慮することで、ダウンタイムの多くを防止できます。必要になる前に予備のハードウェアを購入していないと、用意があれば数分の停止で済んだところが数時間から数日かかる、という状況に陥ることも考えられます。 特別な事象の場合に何を実行すべきかを計画することはまったく性質が異なり、人員や施設の損失を考慮に入れる必要があります。この場合、計画の中心は、重要データを特定し、重要なデータを現場以外に保存する SLA を作成することです。 |
| • | 範囲と許容度 厳格で絶対的な計測要件は、良い影響よりも悪影響をもたらす可能性があります。SLA では、平均的な、または期待されるパフォーマンスを考慮し、適度な変動がある許容度を組み込みます。 |
| • | 可測性 どの SLA でも、基本として客観的な計測方法が必要です。計測が高費用である場合、困難である場合、または不正確である場合は、変更します。多くの場合、機能の計測方法は複数存在し、困難な計測方法は単純な計測方法で代用できます。 たとえば、メールボックスの可用性を計測する場合、Microsoft では、個々のメールボックスが停止した実時間を計測する代わりに、データベース時間で計測しています。メールボックス時間で計測する場合、各データベースのメールボックスをカウントして、各データベースが停止するたびに特定の計算を行う必要があります。データベース時間で計測する場合、各データベースには平均数のメールボックスがあるものとして扱うため、計測が単純になり、全体で見ると同じ結果になります。 別の観点から見ると、可測性とは、計測につきもののエラーの許容誤差といえます。Microsoft には、世界中に数十のドメイン コントローラや Exchange サーバーがあります。"時間誤差" は、すべてのコンピュータが、秒単位で常に同期しているわけではない、ということを指します。実際、コンピュータによっては、1 分以上異なることもあります (最大 5 分の時間誤差まで許容できます)。そのため、Microsoft で電子メール メッセージの配信時間を計測している方法は、厳密には科学的ではありません。場合によって、時間誤差のために ping メッセージが送信された時間より前に受信したように、配信で計測されることがあります。また、メッセージが許容範囲よりも遅く受信したように見えて、実際は許容範囲内にあったということもあります。Microsoft のメール配信 SLA はそれほど厳格ではないため、ランダムな時間誤差エラーによって、結果の良い週と悪い週の違いが出ます。 メモ Exchange 製品チームは、間もなく Microsoft Operations Manager (MOM) 2005 の更新を配布する予定です。MOM を使用すると、メール配信時間の計測時に、時間誤差の問題を防ぐことができます。Microsoft IT では、この更新を 2004 年 12 月に開始します。 |
| • | 実現性 改善目標を設定する前に、計測に関して現在のパフォーマンス ベンチマークを調査し、現在のパフォーマンスとかけ離れた目標を設定しないようにします。SLA の目標が、何週も続けて達成できない場合、その目標は真剣に受け止められなくなります。 |
Microsoft IT は、電子メール サービス全体の品質を追跡するうえで、具体的に 3 つの計測を最も重要な "計器盤" と定義しました。Microsoft の上層部は、毎週、この 3 つの計測をレビューし、メッセージング チームは、より詳細な計測結果を解析します。
| • | メールボックスの可用性 Exchange データベースがマウントされ、クライアント接続に応答可能である場合、そのメールボックスは使用可能と見なされます。ネットワークが停止していてクライアントがデータベースにアクセスできない場合でも、使用可能と見なされます。この計測は、前述のようにデータベース時間で実行され、目標は 99.99% の可用性です。 メモ 実際には、Microsoft のメールボックス サーバーで可用性を計測する基準として、サーバーとデータベースをクライアントが単に使用できるという以上の要件があります。さらに、データ センターで制御されているネットワークの一部も機能している必要があります。 |
| • | メール配信時間 Microsoft 社のネットワーク内で送信される内部電子メール メッセージの 99% は、世界中どこでも 90 秒以内に配信される必要があります。 |
| • | 電子メール クライアントの可用性 Outlook クライアントはすべて、99% の時間、メールボックス サーバーにアクセスできる必要があります。計測の適切な細かさを維持するために、これはメールボックスの可用性とは別に計測されます。サーバー側の問題に対処できるユーザーは、広範なネットワークやクライアント側の問題に対処するユーザーとは異なります。それぞれの計測基準を区別することで、メッセージング チームは、稼動率を改善するためにどこに注目すべきかという重要な質問に自動的に回答したり、各チームが進捗状況を評価するために使用できるデータを提供できます。 メモ Microsoft IT では、クライアント側の週ごとの可用性が、前四半期の 99.97% よりも高い平均値になり、99.99% に達する回数も増えています。 |
Microsoft IT で行っている他の計測方法については、このドキュメントの「進捗状況のレビュー」を参照してください。
可用性の実現と維持
Microsoft IT の場合、高可用性の実現と維持には、主に次の 4 つの分野に留意する必要がありました。
| • | ハードウェアとソフトウェア |
| • | アーキテクチャとトポロジ |
| • | 運用 |
| • | 進捗状況のレビュー |
ここでは、Microsoft で Exchange の可用性を改善するときに役立った、各分野の主要因を中心に説明します。
ハードウェアとソフトウェア
Exchange Server 2003 は、Exchange 初の商用製品である Exchange 4.0 とはまったく異なる製品で、運用方法も異なります。エンタープライズ環境の一般的な Exchange サーバーでは、数百ではなく数千単位のメールボックスが管理されています。平均的ユーザーが送受信する電子メール メッセージ量は、数年前よりも数倍増えています。また、インターネットは、メッセージング サーバー経由で送信されるスパムや他の悪意のあるソフトウェア (マルウェア) があふれ、はるかに厳しい環境となっています。サーバー、ネットワーク、大容量ストレージ デバイスはいずれも、Exchange が初めて導入された時期と比べて、容量と速度が何倍にもなりました。
Exchange Server 2003 の機能セット、スケーラビリティ、信頼性は、ソフトウェア プラットフォームとして、大幅に改善されました。そのため、ハードウェアや Microsoft Windows® プラットフォームの機能を活用し、新たな脅威にも対処できるようになりました。
| • | Exchange Server 2003 では、サーバーまたはクラスタ化された仮想サーバーごとに、20 までのデータベースをサポートしています。Microsoft では、メールボックス サーバーは通常、20 データベースという完全搭載で、約 4,000 のメールボックスをサービスしています。20 のデータベースにメールボックス データを分割することで、各データベースは、1 時間以内に完全復元することが可能となり、また、どのデータベースも必要に応じて同時に復元できるサイズになります。 メモ Exchange 2000 Server がリリースされた時点で、Microsoft は、最適なサーバー パフォーマンスを実現するために、できるだけ少ないストレージ グループとデータベースで各サーバーを構成することを推奨していました。Exchange 2000 Service Pack 3 と Exchange Server 2003 で改善が行われた結果、データベースを追加しても、パフォーマンスの低下というデメリットはなくなりました。現在では、複数データベースにメールボックスを分割することで、高いフォールト トレランスや管理可能性を実現しています。追加のサーバーを購入する必要はありません。 |
| • | Exchange データベース エンジンは、パフォーマンス、復元可能性、およびスケーラビリティの点で、大幅に改善されました。Exchange Server 2003 Service Pack 1 では、データベース ページに 1 ビットの物理的な破損がある場合、自動的に修復されます。これによって、ハードウェアやディスクの問題によってデータベースの任意の場所が破損しても、自動的に修復されます。データベースを復元する必要はありません。オンラインのメンテナンスと最適化のタスクが調整されたため、オフラインでのメンテナンスや最適化というルーチンは不要になりました。この他にも多くの改善点があり、古いバージョンの Exchange と比較すると、Exchange Server 2003 のダウンタイム要件の予測は、はるかに低くなりました。 |
| • | バックアップと復元のテクノロジは、過去数年で単に発展しただけでなく、革命的に変わりました。ストレージ エリア ネットワーク (SAN) と iSCSI (Internet Small Computer System Interface) のストレージ テクノロジは、難解で手が届かないほど高価なものではなくなりました。ストレージは、1 つのサーバーに直接連結されるのではなく、共有や移動が可能になりました。クローンとスナップショット バックアップのテクノロジによって、ほとんど瞬間的に、ばく大な量のデータを効率的に移動し、復元できるようになりました。現在では、災害が発生しても、以前よりも迅速に、Exchange データを復元できます。 |
| • | Windows Server 2003 のクラスタ化サポートは成熟しており、Exchange と高い連携性があります。いくつかの遠隔地では例外はありますが、Microsoft のメールボックスはいずれも、7 ノードの Windows Server 2003 クラスタで管理されています。クラスタ化によって、予測されるダウンタイムが大幅に減りました。これは、Exchange の仮想サーバーは、1 つの Windows ホストに縛られないため、ソフトウェアの更新やハードウェアのメンテナンスが必要な場合でも、クラスタ ノード間で移動できるようになったためです。それでも、予測されるダウンタイムが完全になくなることはありません。クラスタ ノード間で Exchange サービスを移動するときに、数分かかる可能性があるためです。ただし、Exchange サービスは、計画的なインストール、再起動、ハードウェアの置き換えの間、最初から最後まで停止する必要はありません。 Microsoft では、クラスタ化された Windows Server 2003 サーバーで Exchange を管理する以前、予測されるダウンタイムと予測できないダウンタイムの比率は 7 対 1 でした。現在では、予測できないダウンタイムの総数は同じという状況で 1 対 1 となりました。 クラスタ化は、"予測できない" ダウンタイムに対処して高可用性を確保するソリューションであると多くの人は考えます。確かに、ある程度はそう言えます。ただし、現在のエンタープライズ クラスのハードウェアは、数年前のハードウェアと比較して、一般に、高い信頼性があります。エンタープライズ クラスのサーバーやストレージ エンクロージャは、ソフトウェアやアプリケーションのクラスタ化を導入していなくても、高レベルの冗長性、早期のエラー警告、ホット スワップという機能を備えています。 現在のエンタープライズ クラスのハードウェアで Windows Server 2003 のクラスタ化を利用する最大のメリットは、おそらく、フェールオーバー機能ではなく、"予測される" ダウンタイムに対する管理の柔軟性と効果であると言えます。予測されるダウンタイムを減らす方法を見つけることができれば、予測できないダウンタイムに対処する能力を向上するよりも、可用性を向上できます。Exchange 環境で Windows クラスタ化を実装するかどうかにかかわらず、サーバーまたはサービスが停止するたびに、イベントをログに記録して、停止を防ぐことができたかどうか、また影響を軽減することができたかどうかを分析する必要があります。 Microsoft で Exchange メールボックスのクラスタをどのように構成および管理しているかの詳細については、http://www.microsoft.com/services/microsoftservices/exchange.mspx#69 に掲載されている IT Showcase のホワイト ペーパー「Exchange 2003 Design and Architecture at Microsoft」 (英語) を参照してください。 メモ Windows Server のクラスタ化テクノロジの実装により、Exchange のサポート スタッフから専門家を補充する必要がでてきます。現在のスタッフは Exchange を理解するだけでなく、クラスタ化環境で Exchange を運用する場合のクラスタ動作、その他の動作、要件についても理解しておく必要があります。一般に、Exchange サーバーをクラスタ化しない場合、全体の可用性として 99.5% を実現できる必要があります。現時点でこのレベルに達していない場合、Exchange のクラスタ化よりも、運用方法や他の点を改善することで、より迅速に可用性が向上する可能性があります。クラスタ化だけでは、運用上の欠陥や、不適切であるか信頼できないハードウェアとインフラストラクチャには対処できません。99.5% の可用性 (1 年に 1 台のサーバーにつき約 2 日間のダウンタイムが発生した場合に相当) を実現した後で、クラスタ化を導入すると、劇的に可用性が向上します。特に、予測されるダウンタイムが減少します。 |
アーキテクチャとトポロジ
Exchange サーバーを 1 つインストールする作業は単純です。特に、Exchange Server 2003 の新しいツールである "デプロイメント ツール" のステップバイステップの手順に従えば実に簡単です。それでも、サポート可能な Exchange システムを世界規模またエンタープライズ環境で展開するには、高度に専門的な知識が必要です。Exchange と Active Directory の相互作用には、注意と、慎重に検討した設計が必要です。Microsoft の展開ガイドとホワイト ペーパーはわかりやすく、システム設計者が、効果的な Exchange システムを設計し構築するときに役立ちます。Exchange の展開方法の詳細については、http://www.microsoft.com/japan/technet/prodtechnol/exchange/2003/library/default.mspx に掲載されている「展開」を参照してください。
Microsoft IT では、これらのドキュメントに記載されているアドバイスや背景情報のほかに、次のような Exchange 設計の原則が役に立つと考えています。
| • | フォールト トレランスのために、分散型フロントエンド サーバーを使用すること。地理的な境界内で、フロントエンド サーバーを複数のデータ センターに分散します。 |
| • | Exchange 専用の Active Directory サイトを作成すること。こうすることで、Exchange で使用するディレクトリ サーバーの負荷が、より定常的で安定したものとなります。 |
| • | できるだけ大規模なデータ センターにサービスを統合し、集中管理すること。集中管理によって、管理可能性が向上します。また、データ センターは大規模になるほど、高い品質と信頼性を期待できます。 |
管理者およびトラブルシューティング担当者が、既存の展開を分析したり理解しやすいように、Microsoft Exchange Server ベスト プラクティス アナライザ ツール (ExBPA) という新しいツールがリリースされました。ExBPA では、既存の Exchange 組織の 1,200 を超える構成要素をスキャンし、800 を超える組み込み規則を使用して、最適とはいえない構成や、アーキテクチャ設計の問題を検出します。ExBPA の詳細については、http://www.microsoft.com/japan/exchange/downloads/2003/exbpa/default.mspx に掲載されている「Exchange Server ベスト プラクティス アナライザ ツール バージョン 2 のダウンロード」を参照してください。
運用
Microsoft のメッセージング担当者が社外の顧客に対してコンサルティング サービスを提供する場合、システムを監視していないことが、最も一般的な失敗の原因となるようです。このような失敗は、次に示す 2 つの共通の問題の原因になります。
| • | 初期に発見されていれば容易に処理できていたが、発見が遅れて制御できなくなる問題 |
| • | 障害への対応時間が、数分ではなく数時間かかる問題 |
高可用性を実現するため、運用の効率性と一貫性は重要です。メッセージング サポート担当者が、エンド ユーザーからのクレームによって電子メールの問題を認識しているようでは、システム監視は適切に行われていません。高可用システムを維持するために、Exchange 管理チームは、問題の発生を最初に認識する必要があり、さらに、システムが正しく機能していることを毎日検証する必要があります。
Microsoft Operations Manager 2005
Microsoft IT は、MOM 2005 開発チームと密接に連携しています。MOM では、Microsoft IT が開発した、アプリケーションやサーバーのパフォーマンス監視についての知識をカプセル化しています。Microsoft 内部で、MOM によって多数の自社製ツールが置き換えられました。Microsoft IT からのフィードバックは、MOM の新機能を開発するうえで、原動力であり続けています。個々のアプリケーション向けに調整される MOM の Management Pack に、Microsoft 社内のアプリケーション開発グループが貢献しています。
MOM の Exchange Management Pack は、Microsoft IT のメッセージング チームからの大量のフィードバックと指導を受けて、MOM と Exchange の製品チームが共同開発しました。Exchange サーバーの監視専用に、数多くの警告が事前定義され、各警告に関して、詳細なトラブルシューティング情報や説明があります。Microsoft IT と Exchange の両製品グループは、MOM 2005 と MOM の Exchange Management Pack を強く推奨します。これは、重要な Exchange サーバー管理データの収集や分析が自動化されるためです。
24x7x365 の運用可用性
Microsoft IT のスタッフは、社の Exchange サーバーを 24 時間/日、7 日間/週、365 日間/年 (24x7x365) にわたって監視しています。多くの組織では、このような費用をかけることができないため、メッセージング サポート担当者がポットベルを携帯しています。この方法では、問題が検出されてからサポート担当者が対応するまでの迅速さに違いが生じます。また、達成できる可用性にも 99.9% と 99.99% という違いが生じる可能性があります。可用性目標にかかわらず、夜間でも日中でも、警告のたびに応答する責任を持つ人員が必要です。
障害復旧計画
問題が発生したときに対応できる人員を用意することと同様に、システムについて熟練し、熟知している人員を用意することも不可欠です。サポート担当者は、日常の管理タスクや監視タスクを実行できるレベルで優秀なだけでなく、災害後のシステムの再構築方法も理解している必要があります。
Microsoft IT には、日常のメンテナンス、監視、管理の各タスクを実行するための、ステップバイステップ ガイドがあります。ただし、非日常的な災害からの復旧に使用できるステップバイステップ ガイドはありません。これは、広範囲に及ぶ災害の場合、システムから地域のサイト全体または Active Directory 情報まで、システムの最重要な部分が完全に破壊される可能性が高いためです。担当者は、非日常的な災害に対処するため、重要な各システムの再構築に関する訓練を受け知識を習得し、また停止したサイトやサービスを迂回できるアーキテクチャを十分に把握する必要があります。システムが稼動不能になったり重要な担当者が不在である場合を想定して、定期的な火災訓練やシミュレーションを行うことは、非日常的な災害に対する管理能力の弱点を見つける方法として有効です。
システム構成に関する正しいスキルとわかりやすいドキュメントがあれば、Exchange サポート チームは、最初から Exchange 組織を再構築する場合に効率的に行えます。チームが再構築できるかどうかをテストするには、チームに、ラボ環境で Exchange 組織全体を復元させてみます。この場合、データベースのバックアップと、システムのアーキテクチャに関するドキュメントのみを使用します。
非日常的な災害後に復旧するには、担当者が、次の項目を実行する方法を知っている必要があります。
| • | Exchange サーバー全体 (Exchange クラスタが使用されている場合は、仮想サーバーも含みます) の再インストールと再構築の方法 |
| • | ユーザー オブジェクトと Exchange メールボックスの構成属性をインポートおよびエクスポートする方法 |
| • | メールボックスとデータベースを異なるサーバーに移動する方法 |
| • | 異なる Active Directory ユーザー オブジェクト間で、メールボックスを接続および接続解除する方法 |
| • | 復元ストレージ グループと "ダイヤル トーン" の復元戦略の使用 |
| • | Exchange プロトコル仮想サーバーの構成 |
以上に関するホワイト ペーパーと Exchange の技術ドキュメントについては、http://www.microsoft.com/japan/technet/prodtechnol/exchange/2003/library/default.mspx に掲載されている「Exchange Server 2003 管理」を参照してください。
さらに、次の Microsoft サポート技術情報の Knowledge Base の文書に、Exchange メールボックスと Active Directory ユーザー アカウントの連携に関する重要な背景と詳細の説明があります。
| • | 「Exchange 2003 を同じサーバー名のまま新規のハードウェアに移動する方法」 |
| • | 「[XADM] 受信者更新サービスを無効にするための要件」 |
| • | 「Exchange で重複した不要なプロキシ アドレスを削除する」 |
| • | 「[XADM] Ldifde を使用してユーザーの電子メール アドレスを修正する方法」 |
| • | 「[XADM] Mbconn.exe ユーティリティに関する問題の回避方法」 |
進捗状況のレビュー
おそらく、最も困難な仕事は、継続的なレビュー プロセスを作成し、遵守することです。けれどもこれらの作業は不可欠です。
Microsoft IT のレビューは毎週行われます。毎週レビューすることにより、だれの記憶にも新しく、トラブルシューティングや根本的原因を分析するためにデータを集めることのできる状況で、問題に対処することができます。
メッセージング チームで毎週行われるレビューによって、システム パフォーマンスが SLA で設定した制限内にあるかどうか確認されるだけでなく、正しい内容が計測されているか、特定の計測が改善に寄与しているかについても評価が続けられています。また、現在の数値と以前の計測結果を比較した、重要な統計情報や傾向もレビューに含まれています。レビュー範囲には、可用性だけでなく、他の重要なシステム計測基準も含まれます (トラフィック量、ユーザー数、さまざまなサービスのユーザー比率など)。
Exchange システムのサポート チームは、ヘルプ デスクの電話は担当していませんが、ヘルプ デスクの統計情報もレビューしています。ヘルプ デスクに報告される問題数を減らし、通話をより短時間で終わらせることを自分たちの責任と考えているのです。
Microsoft で毎週レビューが行われる計測には次のようなものがあります。
| • | Exchange サーバーの可用性 データベースがマウントされ、正常に動作し、クライアントにサービスできる状態にある時間比率が計測されます。 |
| • | 配信されるメールの比率 (SLA の範囲内) 社内で送受信される 99% を超える電子メール メッセージが、90 秒以内に配信されるかどうかが計測されます。 |
| • | "ダイヤル トーン" メールボックス アクセス 停止後にメール サービスの復元が 1 時間未満で完了したかどうかがレポートされます (過去のメールボックス データをすべて復元する場合は、2 日以内で完了する必要があります)。 Microsoft IT は、どのメールボックス データベースでも復元が 1 時間で完了するように、データベースのサイズを決め、バックアップ システムを調整しています。停止の性質とタイミングによって、メッセージング チームは、全ユーザー データとサービスを同時に復元する方法と、サービスを先に復元してから過去のデータを復元する方法のいずれかを選択します。簡単な "ダイヤル トーン" 復元用に Exchange をセットアップする方法の詳細については、http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ue2k3rsg.mspx に掲載されている「Using Exchange 2003 Recovery Storage Groups」 (英語) を参照してください。 |
| • | 電子メール クライアントの可用性 Microsoft Outlook® クライアントが各 Exchange サーバーに接続できるかどうかを計測します。この計測基準は、標準的なリモート プロシージャ コール (RPC) 接続と、ハイパーテキスト転送プロトコル (HTTP) 経由の RPC 接続の両方に使用されます。Outlook Web Access や他のクライアント プロトコル接続は、別の SLA で計測されます。 |
| • | 電子メール クライアントのパフォーマンス この計測では、サーバーとクライアント間の各要求の応答性を追跡します。Microsoft IT の場合、この計測基準は、2 秒未満で完了するクライアント操作の比率です。この計測基準は、負荷分散とサーバーのサイズを決定するときにも有効です。 |
| • | クローズされた電子メールのサービス要求 (SLA の範囲内) ヘルプ デスクからの要求を解決した速度が計測されます。また、Microsoft IT は、援助を必要とする緊急の要求に特に対処できるように、作成された SR (サービス要求) 数と、その解決優先度も追跡しています。 |
| • | メッセージ クライアントの満足度 (不満足の比率) これは、ヘルプ デスクの要求に対して行われたフォローアップ調査に基づきます。 |
| • | 電子メールの使用 この統計情報には、インターネットで送受信した電子メール メッセージ数と、社内で送信されたメッセージ数が含まれます。 |
| • | 電子メール ユーザー この統計情報には、システムのメールボックス総数、ユーザーのメールボックス数対システムのメールボックス数、システム最大の Exchange サーバーのユーザー数が含まれます。 |
| • | 電子メール インフラストラクチャ この統計情報には、Microsoft のメッセージ サーバー総数とバックアップの成功率が含まれます。 |
| • | メッセージの健全性 この統計情報では、検出されたスパム メッセージ数、メッセージから削除されたウイルス数、インターネット セキュリティと攻撃に関する類似の調査が追跡されます。また、Microsoft IT は、スパムのフィルタリングに関するヘルプ デスクのクレームも追跡し、不要な電子メール メッセージを適切にブロックするときの成功処理を評価しています。 |
| • | モバイル メッセージ Exchange のフロントエンド サーバーの可用性を計測することと、Outlook Web Access ユーザー、Exchange Active Sync ユーザー、Microsoft Outlook Mobile Access ユーザーの数に関する統計情報も含まれます。また、このサービスの使用は、ユーザー コミュニティの比率という点で組み込まれています。このようにすることで、採用と使用の比率が容易に追跡できます。 |
| • | 統合メッセージと FAX このサービスは、Microsoft Exchange インフラストラクチャでも提供され、サービスの稼動率、可用性、パフォーマンスに関してさまざまな計測が週単位に分析されています。 |
| • | バックアップの成功 バックアップは、全サーバーの 99% が、毎晩完全に成功する必要があります。バックアップの成功の計測は、バックアップ システムの信頼性を改善するために行うだけでなく、バックアップ エラーをすぐに認識し、解決するために行います。 |
以上の計測は、他の組織が Exchange システムのパフォーマンスを計測する方法として遵守すべき詳細計画ではありません。Microsoft IT の計測内容は、長い間に変化してきました。また、環境的な理由や問題が生じた場合は、今後も変化します。
毎週のレビューでは、計測を報告し、基準を逸脱した原因について詳細を調査する担当者が、個々の計測を所有しています。最新および過去の計測内容と傾向を箇条書きにした週間スコアカードを元にしたすべての計測内容は、チーム全体が利用できます。この計測内容は、四半期レポートと年間レポートにまとめられ、Microsoft のインフォメーション責任者 (CIO) がレビューします。したがって、チーム全体が日常的に全体像を確認でき、ソリューションの発見と改善に役立てることができます。チームでは問題を毎週レビューしているため、チームの創造性とソリューションの直接的な効果は、現在と過去のパフォーマンス計測の比較に反映されます。
まとめ
高可用性を実現し、維持するためには、プロセスとテクノロジの継続的な改善が必要であり、日常的なレビューやシステム稼動状態についてのリアルタイムでの監視も同時に行います。
永続的に高可用性を維持できるような、決まった規則はありません。高可用性を維持するには、新たな状況やテクノロジに絶え間なく対応し、採用するという、積極的で継続的な努力が求められます。システムの可用性を 24x7x365 にするには、少なくとも 24x7x365 の間、システムで何が発生しているかに注意を払う必要があります。
可用性の改善に重点を置いて検討することが初めてである場合、単純な動作や手順を変更することで、大幅な変化が見られる可能性は高くなります。これは良いニュースでもあり、悪いニュースでもあります。基本的な運用タスクのパフォーマンスを見過ごしてきたことや、運用に一貫性がなかったことがわかり、残念に思う場合も考えられます。
たとえば、Microsoft のコンサルタントやサポート担当者によると、顧客サイトで災害後に発生する最も一般的な問題の 1 つに、重要データのバックアップを作成していないことや検証していないことが挙げられます。これは初歩的なことのようですが、実によく見られる失敗です。このような問題を落ち着いて修正し、週を追うごとに、その前週よりも改善されるようにすることが、成功への近道です。
適切なテクノロジと適切な手順を実施した後に、高可用性を維持するには、定期的な毎週のレビューを実施する規律と義務感が必要になります。レビューにより問題の存在や正常に動作していないことが明確になるため、レビューは避けられる傾向にあります。また、レビューは決まりきった内容に退化しやすく、単なる言い訳や非難の場になりやすい傾向も見られます。高可用性を実現するためにレビュー プロセスは効果的であり、参加者間で価値のある業務であるというコンセンサスを形成することが必要です。
言い訳しない方法を採用し、進捗状況を日常的に監視することで、現在利用できる資金や技術的リソースにかかわらず、組織の可用性レベルを改善することができます。一定レベルに達した場合、さらに可用性を改善するには、テクノロジやインフラストラクチャへの新たな投資が必要になります。
新しいテクノロジを適用することで最適な解決方法を得られる問題と、実践方法を変えることで解決する必要がある問題とを、明確に理解することが重要です。運用方法を改善した状態で新しいテクノロジや機能を導入すると、効果がさらに高まります。
高可用性は、テクノロジ、インフラストラクチャ、運用、定期的なフィードバックとレビューの相乗効果によって実現されます。
詳細情報
インターネットでは、次の Web サイトで弊社の情報をご覧いただけます。
http://www.microsoft.com/japan/
http://www.microsoft.com/japan/showcase/
http://www.microsoft.com/japan/technet/itsolutions/msit/default.mspx