翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# アーキテクチャのコンポーネント
<a name="architecture-components"></a>

このセクションでは、以下の重要な機能アーキテクチャコンポーネントの仕様について概説します。
+ **SAS サーバー** – 分析処理の中央コンピューティングコンポーネントであり、ローカルの直接アタッチストレージ (DAS) を備えています。
+ **SAS サブバージョンサーバー** – SAS の一元的なバージョン管理システムとして機能します。
+ **Amazon FSx for Windows File Server** – SAS サーバーとターミナルサーバー間でストレージを共有するための SMB ファイルサーバーであり、FSx for Windows File Server には、前処理または後処理されたデータファイルを保存しアーカイブします。
+ **Microsoft Remote Desktop Services (RDS) (ターミナルサービスとも呼ばれる)** – これにより、SAS クライアントを使用して SAS サーバーにアクセスできるようになります。
+ **インフラストラクチャの自動化** – AWS Cloud Development Kit (AWS CDK) を AWS CodePipeline および AWS CodeCommit と共に使用​​すると、インフラストラクチャを自動化できます。CodePipeline を使用すると、インフラストラクチャコンポーネントをプロビジョニングしやすくなります。このデリバリーサービスである CodePipeline により、コードリリースに必要なステップのモデル化、視覚化、自動化を行えます。さらに、共有中央環境を実現して、インフラストラクチャをローカルマシンから独立させて管理できます。CodeCommit は、セキュリティとスケーラビリティに優れた、フルマネージドのソース管理サービスであり、プライベート Git リポジトリのホストを可能にします。CodeCommit を使用すると、AWS CDK のインフラストラクチャ自動化コードやパラメータを保存することもできます。

## 環境分離
<a name="environment-separation"></a>

次の図は、SAS 統合環境と SAS 本番環境を分離するためのアーキテクチャを示しています。

![\[SAS 統合環境と SAS 本番環境を分離するためのアーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/data-storage-decoupling-sas-fsx/images/diagram_separation_integration_production.png)


## インフラストラクチャコンポーネント
<a name="infrastructure-components"></a>

このセクションでは、このガイドの推奨アーキテクチャに必要なインフラストラクチャコンポーネントを概説します。

### 本番環境
<a name="prod-environment"></a>

本番環境には、次のインフラストラクチャコンポーネントの使用をお勧めします。


|  |  |  | 
| --- |--- |--- |
| **タイプ** | **インスタンスタイプ** | **リソース** | 
| **SAS サーバー x** 1 | m6i.4xlarge | 16 vCPU (8 コア)64 GB RAM | 
| **Citrix ターミナルサーバー x 2** | m6i.4xlarge | 16 vCPU (8 コア)64 GB RAM (例えば、Microsoft Office と Adobe Suite のユーザーセッションあたり 1～2 GB、SAS クライアントあたり平均 500～1024 MB)25 ユーザー以上将来的に、さらに多くのターミナルサーバーを使用してスケールアウト可能 | 
| **SAS サブバージョンサーバー x** 1 | m6i.2xlarge | 8 vCPUs4 コア32 GB RAM | 

### 統合環境
<a name="integration-environment"></a>

統合環境には、次のインフラストラクチャコンポーネントの使用をお勧めします。


|  |  |  | 
| --- |--- |--- |
| **タイプ** | **インスタンスタイプ** | **リソース** | 
| **SAS サーバー x** 1 | m6i.2xlarge | 8 vCPU (4 コア)32 GB RAM | 
| **ターミナルサーバー x 2** | m6i.2xlarge  | 8 vCPU (4 コア)32 GB RAM | 
| **SAS サブバージョンサーバー x** 1 | m6i.xlarge | 4 vCPU (2 コア)16 GB RAM | 

## SAS サーバーのローカルストレージ
<a name="local-storage-sas-server"></a>

推奨アーキテクチャでは、最新の Intel Xeon スケーラブルプロセッサを搭載する M6i インスタンスを [AWS Nitro System](https://aws.amazon.com/ec2/nitro/) の Nitro Hypervisor で稼働させます。M6i インスタンスタイプは [Amazon Elastic Block Store (Amazon EBS)](https://aws.amazon.com/ebs/) に最適化されており、これによって、ネットワークにアクセス可能な EBS ボリューム専用の帯域幅を得られます。次の表は、非共有ストレージのインスタンスストレージ設定を詳しく示したものです。追加の EBS ボリュームはオンデマンドでアタッチできます。


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **[Server]** (サーバー) | **タイプ** | **容量** | **本番稼働** | **テスト** | 
| SAS サーバー | ストレージタイプ | AWS リソース/サービスおよび EBS タイプ | シーケンシャルな IO (読み取り/書き込み) の要件 | 本番環境と同じ | 
| SAS サーバー | オペレーティングシステムの起動およびスワップ | EBS 200 GB (gp3) | 要件が厳しくないため、サイズ設定に関係なし | 本番環境と同じ | 
| SAS サーバー | SASWORK | RAID 0 を EBS と 512 GB x 2 (gp3 あたり 5,000 IOPS) で構成 | 150 Mbps x 8 (1200 Mbps) または最大 11.5 GbpsM6i インスタンスに対応12.5 Gbps の EBS ストレージ帯域幅 (gp3 EBS ボリュームを使用) | 1024 GB ボリューム x 1gp3 5,000 IOPS | 
| SAS サーバー | SAS Software Depot とその他の補助ストレージ (SAS 関連インストール済みファイルもここに置かれる) | EBS 125 GB (gp3) | 要件が厳しくないため、サイズ設定に関係なし | 本番環境と同じ | 
| SAS ターミナルサーバー | オペレーティングシステムの起動およびスワップ | EBS 100 GB (gp3) | 要件が厳しくないため、サイズ設定に関係なし | 本番環境と同じ | 
| SAS SVN サーバー | オペレーティングシステムの起動およびスワップ | EBS 100 GB (gp3) | 要件が厳しくないため、サイズ設定に関係なし | 100 GB | 
| SAS SVN サーバー | サブバージョンリポジトリ | EBS 1000 GB (gp3) | デフォルト | 運用に必要なドライブに加えて 400 GB | 

## 共有ストレージインフラストラクチャ
<a name="shared-storage-infrastructure"></a>

SAS サーバーと Citrix ターミナルサーバーの共有ストレージソリューションとして、FSx for Windows File Server の使用をお勧めします。システム情報または自動化スクリプトの維持にバケットが必要でない限り、S3 バケットを、追加のファイルストレージに使用する必要はありません。

サブバージョンを使用してチェックアウトしたプロジェクトコードの作業用コピーは、FSx for Windows File Server に保存することもできます。SAS サブバージョンサーバーのリポジトリは、ローカルに保存します。このサーバーは、中央バージョン管理システムとして機能します。

Windows ユーザープロファイルは、FSx for Windows File Server を使用し、Citrix ターミナルサーバーをまたいで保存すると良いでしょう。これによって、両サーバー間でシームレスな負荷分散を行えるようになります。

### 本番環境
<a name="shared-prod-environment"></a>

このガイドのアーキテクチャは、以下に示す本番環境要件を満たすように設計されています。
+ **ストレージタイプ** – FSx for Windows File Server
+ **タイプ** – 複数アベイラビリティーゾーン
+ **リソース/スループット** – 1024 MB
+ **ストレージ** – 1.2 TB SSD

### 統合環境とテスト環境
<a name="int-test-environment"></a>

このガイドのアーキテクチャは、以下に示す統合環境要件を満たすように設計されています。
+ **ストレージタイプ** – FSx for Windows File Server
+ **タイプ** – 複数アベイラビリティーゾーン
+ **リソース/スループット** – 512 MB
+ **ストレージ** – 512 GB SSD

### パフォーマンス
<a name="shared-performance"></a>

FSx for Windows File Server の I/O スループットは簡単に調整でき、モニタリングニーズに合わせて I/O スループットダッシュボードを構築できます。オペレーションチームがエンドユーザーのニーズに基づいてスループットを調整できるようにすることも可能です。

## バックアップとファイル復旧
<a name="back-up-file-recovery"></a>

SAS のデータはすべて、別の FSx for Windows File Server (永続的ストレージ) に保存されています。FSx for Windows File Server に保存済みのデータには、次の 2 つのレベルのバックアップが実装されています。

1. **30 日間保持****される日次バックアップ** – これらのバックアップは S3 バケットに保持されます。Amazon FSx ボリュームが破損または消失した場合は、このスナップショットベースのバックアップを使用して復旧を行えます。

1. **Microsoft Volume Shadow Copy Service (VSS) を使用して保持されるバックアップ** – FSx for Windows File Server 上のファイルは、スナップショット化され、FSx for Windows File Server 上の特別なストレージパーティションに、バックアップとして無期限に保持されます。バックアップは、FSx for Windows File Server 上の VSS パーティションの使用可能なストレージ (総ストレージ容量の最大 10%) に基づいて行われます。エンドユーザーは、FSx for Windows File Server 上のファイルを破損または失った場合、SAS ターミナルサーバーの Windows File Explorer から自力で直接復元を開始できます。

## ディザスタリカバリ
<a name="disaster-recovery"></a>

このガイドの分離アーキテクチャは、ディザスタリカバリを念頭に置いて設計されています。Amazon FSx は、2 つの AWS アベイラビリティーゾーンにデプロイされます。アクティブな FSx for Windows File Server が存在するアベイラビリティーゾーンが使用できなくなった場合、サービスは自動的にフェイルオーバーされ、ファイル共有サービスは 2 番目のアベイラビリティーゾーンから提供されます。