# ベストプラクティス 11.2 – 可用性を維持するためのアプローチを定義する 単一の技術的要素の障害や AWS サービスの障害に耐えられる回復力のあるアーキテクチャを持つことで、可用性を維持します。メカニズムには、冗長な容量、ロードバランシング、およびソフトウェアクラスターなどが含まれます。 **提案 11.2.1 – リソースの枯渇やサービスの低下による障害を回避する** リソースのオーバープロビジョニング、増加のプロアクティブなモニタリング、および制限の設定による使用量のスロットリングを調査します。 運用上の優秀性の柱では、SAP アプリケーションの状態を理解し、適切なアクションを取るためのさまざまな方法が説明されています。以下を参照してください。[運用上の優秀性]: [1 - 状態の理解と反応ができるように SAP ワークロードを設計する](design-principle-1.md) . パフォーマンスの柱は、容量の適切なサイジングとスケーリングに関するガイダンスによって支援します。[パフォーマンス]: [16 – 継続的なパフォーマンスと最適化のオプションを理解する](design-principle-16.md) . **提案 11.2.2 – 計画保守の戦略を持つ** ビジネスに保守停止を最小限にする要件がある場合は、すべてのレベル、つまり、SAP アプリケーション、データベース、オペレーティングシステム、および AWS でメンテナンス戦略を開発する必要があります。以下の点を考慮してください。 + プライマリノードとセカンダリノードを切り替えるためのレプリケーションおよびクラスターソリューションの使用。 + ローリング停止を容易にするための超過容量と拡張縮小メカニズム。 + 可能な場合は、オペレーティングシステムのライブパッチ適用アプローチの使用。 + [SUSE Linux Enterprise Live Patching](https://www.suse.com/products/live-patching/) + [Red Hat Reducing downtime for SAP HANA ホワイトペーパー](https://www.redhat.com/cms/managed-files/pa-sap-hana-reducing-downtime-overview-f22788pr-202004-en.pdf) + AWS ドキュメント: [AWS Systems Manager Patch Manager パッチグループの使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) + SAP Note: [1913302 - HANA: 短時間のメンテナンスタスクのための DB 接続の中断](https://launchpad.support.sap.com/#/notes/1913302) [SAP ポータルへのアクセス権が必要] + SAP Note: [2077934 - Rolling kernel switch in HA environments (HA 環境でのローリングカーネルスイッチ)](https://launchpad.support.sap.com/#/notes/2077934) [SAP ポータルへのアクセス権が必要] + SAP Note: [953653 - Rolling Kernel Switch (ローリングカーネルスイッチ)](https://launchpad.support.sap.com/#/notes/953653) [SAP ポータルへのアクセス権が必要] + SAP Note: [2254173 - Linux: Rolling Kernel Switch in Pacemaker-based NetWeaver HA environments (Linux: ペースメーカーベースの NetWeaver HA 環境でのローリングカーネルスイッチ)](https://launchpad.support.sap.com/#/notes/2254173) [SAP ポータルへのアクセス権が必要] 一時的にパフォーマンスを高めることによって計画保守の全体的ダウンタイムを短縮する AWS サービスのエラスティック機能も評価してください。例えば、データベースを実行している Amazon EC2 インスタンスのサイズを拡張して、アップグレードアクティビティのために CPU とストレージのスループットを高めたり、EBS ボリュームのタイプを gp2 から io2 に切り替えて、データベースの再編成中のストレージスループットを高めたりします。 **提案 11.2.3 – SAP の単一障害点をソフトウェアクラスターまたはその他のメカニズムで保護する** 高可用性 (HA) クラスタリングソリューションを使用して、アベイラビリティーゾーン間の SAP の単一障害点 (SAP セントラルサービスとデータベース) の自律的フェイルオーバーを実現できます。 複数の SAP 認定クラスタリングソリューションがあり、 [SAP ウェブサイトに記載されています](https://wiki.scn.sap.com/wiki/display/SI/Certified+HA-Interface+Partners) .SAP クラスタリングソリューションは、SAP ではなく、クラスターソフトウェアベンダー自身によってサポートされています。SAP はソリューションを認定しているだけです。カスタムビルドのソリューションは認定されず、ソリューションビルダーのサポートが必要です。 単一障害点にクラスタリングソリューションを使用しないことにした場合は、サービスの復元に関連するエラーを最小化するために、スクリプティングまたはランブックを検討してください。 **提案 11.2.4 – サポートするコンポーネントについては、冗長容量またはオートスケーリング** 使用状況に合った静的、動的、またはスケジュールされた容量変更を評価します。最小容量要件と、障害およびメンテナンスによる影響を調べます。適切な場合は、障害から復旧する時間が得られるように、オーバープロビジョニングします。 AZ 障害の発生時に 100% の容量を維持する必要がある場合は、アプリケーション層を 3 つの AZ に、必要な総容量の 50% ずつデプロイすることを検討してください。 SAP アプリケーションサーバーレイヤーを複数の AZ にデプロイすることに加えて、SAP on AWS ブログ投稿で説明されているようなスケーリングソリューションを検討することもできます。 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling) . + SAP on AWS ブログ: [Using AWS to enable SAP Application Auto Scaling (AWS を使用した SAP アプリケーションのオートスケーリングの有効化)](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/) + AWS ドキュメント: [SAP 向け Amazon EC2 インスタンスタイプ](https://aws.amazon.com/sap/instance-types/) + SAP Note: [1656099 - SAP Applications on AWS: Supported DB/OS and Amazon EC2 products (AWS 上の SAP アプリケーション: サポートされる DB/OS および Amazon EC2 製品)](https://launchpad.support.sap.com/#/notes/1656099) [SAP ポータルへのアクセス権が必要] **提案 11.2.5 – 特定されたすべての障害シナリオに対応する容量を確保する** 以下は、分析の参考になる障害シナリオの例です。シナリオ、分類、および影響の詳細度や範囲は、要件とアーキテクチャによって異なります。 | 障害シナリオの例 | 発生リスクの比較 | | --- | --- | | 計画/管理保守 | 計画 | | リソースの枯渇または侵害 (高い CPU 使用率/ファイルシステムがいっぱい/メモリ不足/ストレージの問題) | ミディアム | | 分散ステートレスコンポーネントの障害 (ウェブディスパッチャーなど) | ミディアム | | 分散ステートフルコンポーネントの障害 (アプリケーションサーバーなど) | ミディアム | | 単一障害点 (データベース/SAP セントラルサービス) | ミディアム | | AZ/ネットワーク障害 | 低 | | コアサービスの障害 (DNS/Amazon EFS/API コール) | 低/中 | | 破損/過失による削除/悪意のあるアクティビティ/コードデプロイの誤り | 低 | | リージョン障害 | 非常に低い | キャパシティ予約に関する詳しいガイダンスは、次をよく確認してください。[信頼性]: [提案 10.2.5 - 容量を確保するための戦略を調査する](best-practice-10-2.md) および AWS のホワイトペーパー: [Architecture Guidance for Availability and Reliability of SAP on AWS (SAP on AWS の可用性と信頼性のためのアーキテクチャガイダンス)](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) . AWS を使用して、アカウント内で利用可能なリザーブドインスタンスを確認できます。 [AWS Cost Explorer RI レポート](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-default-reports.html#ce-ri-reports) . **提案 11.2.6 – 該当する場合は、固有の可用性を持つ AWS のサービスを使用します** いくつかの AWS のサービスは、設計の一部として固有の可用性を備えており、高可用性を実現するために複数のアベイラビリティーゾーンで実行されます。SAP のコンテキストで使用される関連サービスには、以下のようなものがあります。 + AWS サービス: [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/how-it-works.html) + AWS サービス: [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html) + AWS サービス: [Route 53](https://aws.amazon.com/route53/faqs/) + AWS サービス: [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html) + AWS サービス: [Amazon S3](https://aws.amazon.com/s3/) また、踏み台ホストや SAPRouter などのステートレスサービスを使用するコンポーネントは、Auto Scaling グループを使用して高可用性を実現できます。 **提案 11.2.7 – AWS のベストプラクティスに従って、ネットワーク接続を確保する** 使用中の AWS リージョンへのネットワーク接続の回復力を確保するために、以下の AWS ベストプラクティスを 1 つ以上評価すること。 + AWS ドキュメント: [AWS Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html) + AWS ドキュメント: [AWS VPN CloudHub](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-vpn-cloudhub.html) クラスターソリューションがオーバーレイ IP に依存している場合、VPC 外からのアクセスを可能にするために以下を検討してください。 + AWS ドキュメント: [SAP on AWS High Availability with Overlay IP Address Routing (オーバーレイ IP アドレスルーティングによる SAP on AWS の高可用性)](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-ha-overlay-ip.html)