この参照アーキテクチャでは、MinRole トポロジおよび SQL Server Always On 可用性グループを使用して、高可用性 SharePoint Server 2016 ファームを Azure にデプロイするための実証済みプラクティスを示します。 SharePoint ファームは、インターネットに接続するエンドポイントまたはプレゼンスのない、セキュリティで保護された仮想ネットワークにデプロイされます。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
このアーキテクチャは、「n 層アプリケーションでの Windows VM の実行」や「windows-n-tier」に関する記事で示されているアーキテクチャに基づいて構築されています。 Azure 仮想ネットワーク内に高可用性を備えた SharePoint Server 2016 ファームをデプロイします。 このアーキテクチャは、テスト環境または実稼働環境、Microsoft 365 を含む SharePoint ハイブリッド インフラストラクチャに適しており、ディザスター リカバリー シナリオの基礎としても適しています。
コンポーネント
リソース グループは、関連する Azure リソースを保持するコンテナーです。 1 つのリソース グループが SharePoint サーバーに使用され、仮想マシン (VM) に依存しないインフラストラクチャ コンポーネント (仮想ネットワークやロード バランサーなど) には別のリソース グループが使用されます。
Azure Virtual Network は、Azure 内のプライベート ネットワークの基本的な構成ブロックです。 VM は、一意のイントラネット アドレス空間を持つ仮想ネットワークにデプロイされます。 仮想ネットワークは、サブネットにさらに再分割されます。
VM は、Azure で使用できるオンデマンドでスケーラブルなコンピューティング リソースです。 VM は仮想ネットワークにデプロイされ、すべての VM にプライベート静的 IP アドレスが割り当てられます。 静的 IP アドレスは、IP アドレスのキャッシュや再起動後のアドレスの変更に伴う問題を回避するため、SQL Server と SharePoint Server 2016 を実行する VM に推奨されます。
可用性セットは、VM の論理的なグループ化です。 各 SharePoint ロールの VM を個別の可用性セットに配置し、ロールごとに少なくとも 2 つの VM をプロビジョニングします。 この構成により、VM が高度なサービス レベル アグリーメント (SLA) に対応できるようになります。
Azure Load Balancer は、SharePoint の要求トラフィックをオンプレミス ネットワークから SharePoint ファームのフロントエンド Web サーバーに分散させます。 このソリューションでは、内部ロード バランサーを使用します。 HTTP トラフィックの代わりに、Azure Application Gateway を使用することもできます。
ネットワーク セキュリティ グループにより、Azure 仮想ネットワーク内のトラフィックをフィルター処理します。 VM が含まれているサブネットごとに、ネットワーク セキュリティ グループが作成されます。 サブネットを分離するには、ネットワーク セキュリティ グループを使用して、仮想ネットワーク内のネットワーク トラフィックを制限します。
Azure ExpressRoute またはサイト間 VPN (Azure VPN Gateway など) は、オンプレミス ネットワークと Azure 仮想ネットワークの間の接続を提供します。 詳しくは、「オンプレミス ネットワークの Azure への接続」をご覧ください。
Windows Server Active Directory (AD) ドメイン コントローラーは、ドメイン内のユーザーを認証します。 この参照アーキテクチャのドメイン コントローラーは Azure 仮想ネットワーク内で実行され、オンプレミスの Windows Server AD フォレストと信頼関係があります。 SharePoint ファーム リソースに対するクライアント Web 要求は、その認証トラフィックがゲートウェイ接続経由でオンプレミス ネットワークに送信されるのではなく、仮想ネットワーク内で認証されます。 DNS では、イントラネット A または CNAME レコードが作成されるため、イントラネット ユーザーは SharePoint ファームの名前を内部ロード バランサーのプライベート IP アドレスに解決できます。
SharePoint Server 2016 でも、Microsoft Entra Domain Services を利用できます。 Microsoft Entra Domain Services はマネージド ドメイン サービスを提供するので、Azure にドメイン コントローラーをデプロイし、管理する必要はありません。
SQL Server Always On 可用性グループは、高可用性とディザスター リカバリー ソリューションを提供します。 これらを SQL Server データベースの高可用性のためにお勧めします。 SQL Server には 2 つの VM が使用されます。 1 つにはプライマリ データベース レプリカが含まれ、もう 1 つにはセカンダリ レプリカが含まれます。
マジョリティ ノード VM を使用すると、フェールオーバー クラスターでクォーラムを確立できます。 詳しくは、「フェールオーバー クラスターのクォーラム構成について」をご覧ください。
SharePoint Server は、共有アクセスのためのプラットフォームを提供します。 SharePoint サーバーは、Web フロントエンド、キャッシュ、アプリケーション、およびロールの検索を実行します。
ジャンプ ボックス (bastion ホストとも呼ばれます) は、管理者が他の VM に接続するために使用する、ネットワーク上のセキュリティで保護された VM です。 ジャンプ ボックスには、セーフ リスト上のパブリック IP アドレスからのリモート トラフィックのみを許可するネットワーク セキュリティ グループがあります。 このネットワーク セキュリティ グループでは、リモート デスクトップ (RDP) トラフィックを許可する必要があります。
推奨事項
実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。 これらの推奨事項を開始点として使用してください。
リソース グループの推奨事項
サーバー ロールごとにリソース グループを分け、グローバル リソースであるインフラストラクチャ コンポーネントにも別のリソース グループを用意することを推奨します。 このアーキテクチャでは、SharePoint リソースが 1 つのグループを形成し、SQL Server と他のユーティリティ アセットがもう 1 つのグループを形成します。
仮想ネットワークとサブネットの推奨事項
SharePoint ロールごとに 1 つのサブネット、ゲートウェイに 1 つのサブネット、およびジャンプ ボックスに 1 つのサブネットを使用します。
ゲートウェイ サブネット名は、GatewaySubnet にする必要があります。 ゲートウェイ サブネットのアドレス空間には、仮想ネットワーク アドレス空間の最後の部分を割り当てます。 詳しくは、「VPN ゲートウェイを使用した Azure へのオンプレミス ネットワークの接続」をご覧ください。
VM の推奨事項
このアーキテクチャでは最小で 44 コアが必要です。
- Standard_DS3_v2 上に 8 つの SharePoint サーバー (それぞれ 4 コア) = 32 コア
- Standard_DS1_v2 上に 2 つの Active Directory ドメイン コントローラー (それぞれ 1 コア) = 2 コア
- Standard_DS3_v2 上に 2 つの SQL Server VM = 8 コア
- Standard_DS1_v2 上に 1 つのマジョリティ ノード = 1 コア
- Standard_DS1_v2 上に 1 つの管理サーバー = 1 コア
Search インデクサーを除くすべての SharePoint ロールについて、Standard_DS3_v2 VM サイズの使用を推奨します。 Search インデクサーは少なくとも Standard_DS13_v2 のサイズにする必要があります。 詳細については、「SharePoint Server 2016 のハードウェア要件およびソフトウェア要件」を参照してください。 SQL Server VM の場合は、少なくとも 4 つのコアと 8 GB の RAM をお勧めします。 詳細については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server)」を参照してください。
ネットワーク セキュリティ グループに関する推奨事項
サブネットの分離を可能にするために、VM が含まれているサブネットごとに 1 つのネットワーク セキュリティ グループを用意することをお勧めします。 サブネットの分離を構成する場合は、各サブネットの許可または拒否される受信または送信トラフィックを定義するネットワーク セキュリティ グループ ルールを追加します。 詳細については、「ネットワーク セキュリティ グループによるネットワーク トラフィックのフィルタリング」を参照してください。
ゲートウェイ サブネットにはネットワーク セキュリティ グループを割り当てないでください。さもなければ、ゲートウェイが機能を停止します。
記憶域の推奨事項
ファームの VM の記憶域構成は、オンプレミス デプロイで使用される適切なベスト プラクティスと一致する必要があります。 SharePoint サーバーではログ用に別のディスクが必要です。 検索インデックス ロールをホストする SharePoint サーバーでは、検索インデックスを格納するために追加のディスク領域が必要です。 SQL Server の場合、標準プラクティスではデータとログを分離します。 データベース バックアップ ストレージにディスクをさらに追加し、tempdb 用に別のディスクを使用します。
最高の信頼性を得るには、Azure Managed Disks の使用を推奨します。 マネージド ディスクでは可用性セット内の VM のディスクが必ず分離されるため、単一障害点を回避できます。
SharePoint および SQL Server のすべての VM で Premium マネージド ディスクを使用してください。 マジョリティ ノード サーバー、ドメイン コントローラー、および管理サーバでは、Standard マネージド ディスクを使用できます。
SharePoint Server の推奨事項
SharePoint ファームを構成する前に、サービスごとに 1 つの Windows Server Active Directory サービス アカウントがあることを確認します。 このアーキテクチャでは、ロールごとに特権を分離するために、少なくとも次に示すドメインレベル アカウントが必要です。
- SQL Server サービス アカウント
- セットアップ ユーザー アカウント
- サーバー ファーム アカウント
- Search Service アカウント
- コンテンツ アクセス アカウント
- Web アプリ プール アカウント
- サービス アプリ プール アカウント
- キャッシュ スーパー ユーザー アカウント
- キャッシュ スーパー リーダー アカウント
最小 200 MB/s のディスク スループットのサポート要件を満たすには、必ず検索アーキテクチャを計画してください。 「SharePoint Server 2013 でエンタープライズ検索アーキテクチャを計画する」をご覧ください。 また、「SharePoint Server 2016 のクロールのベスト プラクティス」のガイドラインに従います。
さらに、検索コンポーネント データを、パフォーマンスに優れている別の記憶域ボリュームまたはパーティションに格納します。 負荷を減らしてスループットを向上するには、オブジェクト キャッシュ ユーザー アカウントを構成します。これはこのアーキテクチャで必要です。 Windows Server オペレーティング システム ファイル、SharePoint Server 2016 プログラム ファイル、および診断ログは、通常のパフォーマンスの 3 つの記憶域ボリュームまたはパーティションに分割します。
これらの推奨事項について詳しくは、「SharePoint Server 2016 での初期展開の管理およびサービス アカウント」をご覧ください。
ハイブリッド ワークロード
この参照アーキテクチャでは、SharePoint ハイブリッド環境として使用できる SharePoint Server 2016 ファームをデプロイします。つまり、SharePoint Server 2016 が SharePoint Online に拡張されます。 Office Online Server がある場合は、Azure での Office Web Apps および Office Online Server のサポートに関する記事をご覧ください。
このソリューションにおける既定のサービス アプリケーションは、ハイブリッド ワークロードに対応するように設計されています。 SharePoint インフラストラクチャを変更せずに、SharePoint Server 2016 および Microsoft 365 のすべてのハイブリッド ワークロードをこのファームにデプロイできます。ただし、1 つの例外として、Cloud Hybrid Search Service Application は、既存の検索トポロジをホストするサーバーにデプロイしないでください。 したがって、このハイブリッド シナリオに対応するためには、1 つ以上の検索ロール用の VM をファームに追加する必要があります。
SQL Server Always On 可用性グループ
SharePoint Server 2016 では Azure SQL Database を使用できないため、このアーキテクチャでは SQL Server VM を使用します。 SQL Server の高可用性をサポートするために、Always On 可用性グループの使用を推奨します。これによって、一緒にフェールオーバーする一連のデータベースが指定され、それらのデータベースの可用性が向上して復旧可能になります。 詳しくは、可用性グループの作成と SharePoint データベースの追加に関する記事をご覧ください。
また、SQL Server VM の内部ロード バランサーのプライベート IP アドレスであるリスナー IP アドレスのクラスターへの追加もお勧めします。
Azure で実行する SQL Server の推奨 VM サイズやその他のパフォーマンスの推奨事項について詳しくは、「Azure Virtual Machines における SQL Server のパフォーマンスに関するベスト プラクティス」をご覧ください。 「SharePoint Server 2016 ファーム内の SQL Server のベスト プラクティス」の推奨事項にも従ってください。
マジョリティ ノード サーバーは、レプリケーション パートナーとは別のコンピューターに配置することをお勧めします。 このサーバーによって、高度セーフティ モード セッションでセカンダリ パートナー サーバーが、自動フェールオーバーを開始するかどうかを認識できるようになります。 2 つのパートナーとは異なり、マジョリティ ノード サーバーはデータベースでは使用されず、自動フェールオーバーをサポートします。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
スケーラビリティ
既存のサーバーをスケールアップするには、VM サイズを変更します。
SharePoint Server 2016 の MinRoles 機能により、サーバーのロールに基づいてサーバーをスケールアウトできます。ロールからサーバーを削除することもできます。 サーバーをロールに追加するときは、単独ロールのいずれか、または組み合わされたロールのいずれかを指定できます。 ただし、サーバーを検索ロールに追加する場合は、PowerShell を使用して検索トポロジも再構成する必要があります。 MinRoles を使用してロールを変換することもできます。 詳しくは、「SharePoint Server 2016 での MinRole サーバー ファームの管理」をご覧ください。
SharePoint Server 2016 では、自動スケーリングのための仮想マシン スケール セットの使用はサポートされていません。
可用性
この参照用アーキテクチャでは、Azure リージョン内の高可用性がサポートされます。ロールごとに少なくとも 2 つの VM が可用性セット内にデプロイされているためです。
リージョン障害に対して保護するには、異なる Azure リージョンに別のディザスター リカバリー ファームを作成します。 目標復旧時間 (RTO) と目標復旧時点 (RPO) によって設定の要件が決まります。 詳しくは、「SharePoint Server 2016 用のディザスター リカバリー戦略の選択」をご覧ください。 セカンダリ リージョンは、プライマリ リージョンと "ペアになっているリージョン" であることが必要です。 広範囲にわたって障害が発生した場合は、すべてのペアで一方のリージョンの復旧が優先されます。 詳しくは、「ビジネス継続性とディザスター リカバリー (BCDR):Azure のペアになっているリージョン」をご覧ください。
管理の容易性
サーバー、サーバー ファーム、およびサイトを運用して管理するには、SharePoint の運用の推奨プラクティスに従います。 詳しくは、SharePoint Server 2016 の運用に関する記事をご覧ください。
SharePoint 環境で SQL Server を管理する際に検討するタスクは、データベース アプリケーションで一般的に検討されるタスクとは異なる場合があります。 ベスト プラクティスは、すべての SQL データベースを週 1 回完全にバックアップし、さらに毎晩増分バックアップすることです。 トランザクション ログは 15 分間隔でバックアップします。 別のプラクティスでは、SQL Server メンテナンス タスクをデータベースに実装し、組み込みの SharePoint メンテナンス タスクは無効にします。 詳しくは、「ストレージおよび SQL Server の容量計画と構成 」をご覧ください。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
SharePoint Server 2016 の実行に使用されるドメインレベル サービス アカウントでは、ドメイン参加や認証のプロセスで Windows Server AD ドメイン コントローラーまたは Microsoft Entra Domain Services が必要です。 ただし、イントラネットに既に配置されている Windows Server AD の ID インフラストラクチャを拡張するために、この特定のアーキテクチャでは、既存のオンプレミス Windows Server AD フォレストの Windows Server AD レプリカ ドメイン コントローラーとして 2 つの VM が使用されます。
また、セキュリティ強化を計画するのは常に賢明です。 他の推奨事項は次のとおりです。
- サブネットやロールを分離するには、ネットワーク セキュリティ グループにルールを追加します。
- VM にパブリック IP アドレスを割り当てないでください。
- 侵入の検出とペイロードの分析のためには、内部 Azure ロード バランサーではなくフロントエンド Web サーバーの前での、ネットワーク仮想アプライアンスの使用を検討します。
- オプションとして、サーバー間のクリア テキスト トラフィックの暗号化のために IPsec ポリシーを使用します。 サブネットの分離も実行する場合は、IPsec トラフィックを許可するようにネットワーク セキュリティ グループ ルールを更新します。
- VM 用のマルウェア対策エージェントをインストールします。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
コストの見積もりには、Azure 料金計算ツールをご利用ください。 ここでは、このアーキテクチャのコストを最適化するためのいくつかの要因について説明します。
Active Directory Domain Services
コストを削減するために、複数のワークロードで使用される共有サービスとして Active Directory Domain Services を使用することを検討してください。 詳細については、「Active Directory Domain Services の価格」を参照してください。
VPN Gateway
課金モデルは、ゲートウェイがプロビジョニングされ、利用可能になっている時間に基づいています。 「VPN Gateway の価格」を参照してください。
受信トラフィックはすべて無料です。 送信トラフィックはすべて課金されます。 インターネット帯域幅のコストは、VPN の送信トラフィックに適用されます。
Virtual Network
Virtual Network は無料です。 すべてのサブスクリプションで、すべてのリージョンで最大 50 の仮想ネットワークを作成できます。 仮想ネットワークの境界内で発信されたすべてのトラフィックは無料です。 そのため、同じ仮想ネットワーク内の2つの VM 間の通信は無料です。
このアーキテクチャは、「n 層アプリケーションでの Windows VM の実行」や「windows-n-tier」に関する記事に従ってデプロイされたアーキテクチャに基づいて構築されています。
詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。
DevOps
運用、開発、およびテスト環境それぞれに対して別個のリソース グループを使用することを検討してください。 個別のリソース グループにより、デプロイの管理、テスト デプロイの削除、およびアクセス権の割り当てが行いやすくなります。 一般的に、同じライフサイクルのリソースは、同じリソース グループに配置します。 開発環境およびテスト環境には、Developer レベルを使用してください。 運用前環境のコストを最小限に抑えるには、運用環境のレプリカをデプロイしてテストを実行し、シャットダウンします。
インフラストラクチャを定義するには、Azure Resource Manager テンプレートまたは Azure Bicep テンプレートを使用します。 どちらの場合も、リソースをデプロイするためのコードとしてのインフラストラクチャ (IaC) プラクティスに従います。 インフラストラクチャのデプロイの自動化には、Azure DevOps Services またはその他の CI/CD ソリューションを使用できます。 デプロイ プロセスは "べき等" でもあります。つまり、同じ結果を繰り返し生成できます。 Azure Pipelines は Azure DevOps Services の一部であり、自動化されたビルド、テスト、およびデプロイを実行します。
ワークロード条件に従ってデプロイ テンプレートを構築し、単一の作業単位を識別して、それらを独自のテンプレートに含めます。 このシナリオでは、少なくとも 7 つのワークロードが識別され、独自のテンプレートに分離されます (Azure 仮想ネットワークと VPN ゲートウェイ、管理ジャンプ ボックス、AD ドメイン コントローラー、SQL Server VM、フェールオーバー クラスターと可用性グループのほか、残りの VM、Sharepoint プライマリ ノード、Sharepoint キャッシュ、ネットワーク セキュリティ グループ ルール)。 ワークロードの分離により、ワークロード固有のリソースをチームに容易に関連付けられるので、チームはこれらのリソースのあらゆる側面を個別に管理できます。 この分離により、DevOps で継続的インテグレーションと継続的デリバリー (CI/CD) を実行できるようになります。 この構成により、ワークロードのステージングも可能になります。これは、さまざまなステージにデプロイし、各ステージで検証を実行してから次に進むことを意味します。 これにより、高度に制御された方法で運用環境に更新プログラムをプッシュし、予期しないデプロイの問題を最小限に抑えることができます。
Azure Monitor を使用して、インフラストラクチャのパフォーマンスを分析および最適化することを検討してください。ネットワークの問題を VM にログインすることなく監視および診断できます。
詳細については、Azure Well-Architected Framework の DevOps に関するセクションを参照してください。
次のステップ
ソリューション アーキテクチャの個々の部分の詳細については、次のトピックを参照してください。
- 可用性セット
- Azure VPN Gateway
- Azure Load Balancer
- SharePoint Server 2016 のハードウェア要件とソフトウェア要件
- SharePoint Server 2016 および 2019 における MinRole サーバー ロールの概要
- Always On 可用性グループ
- SharePoint Server ファームにおける SQL Server のベスト プラクティス
- SharePoint Server 2016 in Microsoft Azure
- Azure Resource Manager リソース グループ
- Microsoft Entra Domain Services