Lync Server 2013 での容量と可用性の管理
トピックの最終更新日: 2014-08-18
容量管理と可用性管理の目的は、システムのパフォーマンスを測定および制御することです。 システムのパフォーマンスを測定および制御できるように、容量管理と可用性管理手順を実装することをお勧めします。 システムが使用可能かどうか、およびベースラインを設定し、システムを監視して傾向を探すことによって、現在および予測される需要を処理できるかどうかを知る必要があります。
容量管理
容量管理には、SLA で指定された最小のパフォーマンス レベルを超えるのを保証するために、サービス容量の計画、サイズ設定、制御が含まれます。 適切な容量管理により、妥当なコストで IT サービスを提供し、SLA で定義されているパフォーマンスレベルをクライアントと共に満たすことができます。 これらの条件には、次のものが含まれます。
システム応答時間 これは、システムが一般的なアクションを実行するために要する測定時間です。 たとえば、オーディオ/ビデオ サーバーの役割がオーディオ/ビデオ トラフィックを処理するために必要な時間、クライアントが会議を作成して参加するために必要な時間、すべてのウォッチャー クライアントでプレゼンスが更新されるのにかかる時間などがあります。
ストレージ容量 これは、コンテンツ データベース、バックアップ デバイス、またはローカル ドライブのいずれであっても、ストレージ システムの容量です。 たとえば、サイトごとに提供される最大ストレージ領域と、バックアップを上書きする前にバックアップを格納する必要がある時間が含まれます。
容量の調整は、ディスク領域やネットワーク帯域幅など、十分な物理リソースが使用可能であることを確認する場合によくあります。 次の表に、容量関連の問題の一般的な解決策を示します。
容量関連の問題の一般的な解決策
| 問題 | 可能な解決 |
|---|---|
オーディオ/ビデオのパフォーマンスが低下しているリモート ユーザー |
WAN リンクで適切な帯域幅が使用可能かどうか、および QoS が有効で適切に構成されているかどうかを確認します。 QoE データを確認します。 |
Lync 環境の全体的な応答が遅い。 |
テストを実行して、既存のフロントエンド サーバーが負荷に対処できることを確認します。 必要に応じて、新しいフロントエンド サーバーを導入します。SQL データベースの応答時間を確認し、遅延の原因を修正します (ディスク I/O の向上など)。 |
トラブルシューティングの詳細については、Lync Server ネットワーク ガイドを参照してください。
容量はシステム構成の影響を受け、ネットワーク帯域幅などの物理リソースに依存します。 たとえば、Lync 環境が夜間に完全バックアップを実行するように構成されている場合は、エンド ユーザーが経験する対話型のパフォーマンスへの影響が最小限に抑えられるよう注意する必要があります。
容量管理は、システムの容量を許容可能なレベルに維持するプロセスであり、次の問題に対処します。
要件の変更に対応する 容量要件は、システムまたは組織の変更を考慮して調整する必要があります。 たとえば、環境でエンタープライズ VoIPの実装を決定した場合、仲介サーバーと公衆交換電話網 (PSTN) ゲートウェイの数と配置が非常に重要になります。 セッション開始プロトコル (SIP) トランキングまたは直接 SIP を実行する場合は、全体的な設計が大幅に変更され、最適なエンタープライズ VoIPパフォーマンスが提供されます。
将来の要件を予測する 一部の容量要件は、時間の経過と共に予測可能に変化します。 傾向を追跡することで、事前にアップグレードを計画できます。 たとえば、ベースラインを作成するには、さまざまな Lync サイト間で使用可能な帯域幅を監視する必要があります。 このベースラインを使用すると、これらのリモート サイトのユーザー数が時間と共に増加するにつれて、これらのリンクに帯域幅を追加する必要があるタイミングを予測できます。
可用性管理
可用性管理とは、IT サービスが一貫してコスト効率よく、お客様が必要とする一貫性のある信頼性の高いサービスのレベルを実現するプロセスです。 可用性管理では、サービスの損失を最小限に抑え、サービスが失われた場合に適切なアクションが実行されるようにします。 Lync 環境では、エンタープライズ VoIP サービスを利用できるかどうか、ユーザーがスケジュールされた会議に参加できるかどうかなどが気になる場合があります。 SLA は、許容できる頻度と停止の長さを定義し、システムが計画メンテナンスで使用できない特定の期間を許可します。
システムの可用性に関するレポートを管理に提供する必要がある場合、または不足している可用性ターゲットに関連する金銭的または他のペナルティがある場合は、可用性データを記録する必要があります。 このような正式な要件がない場合でも、少なくとも特定の期間にシステムが失敗した頻度を把握することをお勧めします。 たとえば、過去 12 か月間のシステムの可用性と、各障害からの復旧にかかった時間などです。 この情報は、システム障害への対応におけるチームの有効性を測定し、改善するのに役立ちます。 また、問題が発生した場合に役立つ情報を提供することもできます。
可用性に関連するメジャーは次のとおりです。
可用性 これは通常、システムまたはサービスがダウンした時刻と比較してアクセスできる時間として表されます。 通常はパーセンテージで表されます。 ("3 ナイン" または "5 ナイン" への参照が表示される場合があります)。これらは、99.9% または 99.999% の可用性を参照します)。
信頼性 これは、システムの障害間の時間の測定値であり、エラー間の平均 (または平均) 時間 (MTBF) として表されることがあります。
修復までの時間 これは、障害が発生した後のサービスの復旧にかかった時間であり、多くの場合、平均修復時間 (MTTR) として表されます。
可用性、信頼性、修復時間は、次のように関連します。
可用性 = (MTBF – MTTR) / MTBF たとえば、サーバーが 6 か月間に 2 回失敗し、平均 20 分間使用できない場合、MTBF は 3 か月または 90 日、MTTR は 20 分です。 そのため、可用性 = (90 日から 20 分) / 90 日 = 99.985% です。
可用性管理は、可用性が最大化され、SLA で定義されているパラメーター内に保持されるようにするプロセスです。 可用性管理には、次のプロセスが含まれます。
監視 サービスが利用できないタイミングと時間を調べる。
レポート 可用性の数値は、管理チーム、ユーザー チーム、運用チームに定期的に提供する必要があります。 これらのレポートでは、傾向を強調し、正常に動作している領域と注意が必要な領域を特定する必要があります。 レポートは、SLA で設定されたターゲットへの準拠を要約する必要があります。
改善 可用性が SLA で定義されているターゲットを満たしていない場合、または可用性が低下する傾向にある場合は、可用性管理プロセスで修復手順を計画する必要があります。 これには、他の責任あるチームと協力して、停止の理由を強調し、停止の再発を防ぐための修復アクションを計画することが含まれる必要があります。
容量と可用性の測定は、このドキュメントの後半で説明する Microsoft System Center Operations Manager (旧称 Microsoft Operations Manager) などの自動化されたツールやスクリプトに最適な反復的なタスクです。