翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
アーキテクチャのコンポーネント
このセクションでは、以下の重要な機能アーキテクチャコンポーネントの仕様の概要を説明します。
SAS サーバー— このサーバーは分析処理の中心的なコンピューティングコンポーネントであり、ローカルの直接接続ストレージ (DAS) を備えています。
SAS サブバージョンサーバー— このサーバは SAS の一元的なバージョン管理システムとして機能します。
Windows ファイルサーバー用 Amazon FSx— これは SAS サーバとターミナルサーバ間でストレージを共有するための SMB ファイルサーバです。エンドユーザーは、前処理されたデータファイルと後処理されたデータファイルをFSx for Windows File Serverに保存およびアーカイブします。
Microsoft リモートデスクトップサービス (RDS) (ターミナルサービスとも呼ばれます)— RDS を使用すると、エンドユーザーは SAS クライアントを使用して SAS サーバーにアクセスできます。
インフラ自動化— AWS クラウド開発キット (AWS CDK) を AWS で使用できますCodePipelineおよび AWSCodeCommitインフラストラクチャーを自動化します。CodePipelineインフラストラクチャコンポーネントのプロビジョニングに役立ちます。CodePipelineは、コードのリリースに必要なステップをモデル化、視覚化、自動化するための継続的デリバリーサービスです。さらに、CodePipeline共有の中央環境を提供し、ローカルマシンから独立したインフラストラクチャ管理を可能にします。CodeCommitは、プライベート Git リポジトリをホストする、安全で拡張性の高いフルマネージド型のソース管理サービスです。使用できますCodeCommitAWS CDK インフラストラクチャ自動化コードとパラメータを保存します。
環境の分離
次の図は、SAS 統合環境と SAS 本番環境を分離するためのアーキテクチャを示しています。
インフラストラクチャコンポーネント
このセクションでは、このガイドで推奨されるアーキテクチャに必要なインフラストラクチャコンポーネントの概要を説明します。
本番環境
本番環境には、以下のインフラストラクチャコンポーネントを使用することをお勧めします。
タイプ | インスタンスタイプ | リソース |
1 台の SAS サーバー | m6i.4xlarge | 16 個の仮想CPU (8 コア) 64 ギガバイトのRAM |
2 台のシトリックスターミナルサーバー | m6i.4xlarge | 16 個の仮想CPU (8 コア) 64 GB RAM (たとえば、マイクロソフトオフィスとアドビスイートではユーザーセッションあたり 1 ～ 2 GB、SAS クライアントあたり平均 500 ～ 1024 MB) 25 人以上のユーザー 将来的にはターミナルサーバーを増やしてスケールアウトする可能性 |
1 つの SAS サブバージョンサーバー | m6i.2xlarge | 8 個の仮想CPU 4 コア 32 GB RAM |
インテグレーション環境
統合環境には、次のインフラストラクチャコンポーネントを使用することをお勧めします。
タイプ | インスタンスタイプ | リソース |
1 台の SAS サーバー | m6i.2xlarge | 8 個の仮想CPU (4 コア) 32 GB RAM |
2 つのターミナルサーバー | m6i.2xlarge
| 8 個の仮想CPU (4 コア) 32 GB RAM |
1 つの SAS サブバージョンサーバー | m6i.xlarge | 4 つの仮想CPU (2 コア) 16 ギガバイトのRAM |
SAS サーバー用のローカルストレージ
推奨アーキテクチャでは、最新のインテル Xeon スケーラブルプロセッサを搭載した M6i インスタンスを使用し、以下の Nitro Hypervisor を使用します。AWS ニトロシステム
サーバー | タイプ | 容量 | プロダクション | テスト |
SAS サーバー | ストレージタイプ | AWS リソース/サービスと EBS タイプ | シーケンスの要件。IO (読み取り/書き込み) | プロダクションと同じ |
SAS サーバー | オペレーティングシステムの起動とスワップ | EBS 200 GB (gp3) | 要件が低いため、サイジングには関係ありません | プロダクションと同じ |
SAS サーバー | 仕事として | RAID 0 の EBS 2x 512 GB (gp3/各 5,000 IOPS) | 8 * 150 Mbps、1200 Mbps、または 11.5 Gbps M6i インスタンスのサポート GP3 EBS ボリュームを使用した 12.5 Gbps の EBS ストレージ帯域幅 | 1024 ギガバイトのボリューム x 1 gp3 5,000 IOPS |
SAS サーバー | SAS ソフトウェアデポとその他の補助ストレージ (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 |
共有ストレージインフラストラクチャ
SAS サーバーと Citrix ターミナルサーバーの共有ストレージソリューションとして FSx for Windows ファイルサーバーを使用することをお勧めします。システム情報や自動化スクリプトの管理に必要な場合を除いて、追加のファイルストレージに S3 バケットを使用する必要はありません。
また、プロジェクトコードの subversion チェックアウト/作業用コピーを Windows ファイルサーバー用の FSx に保存することもできます。SAS Subversion サーバーはリポジトリをローカルに保存します。Subversion サーバーは中央のバージョン管理システムとして機能します。
WindowsユーザープロファイルをCitrixターミナルサーバー全体に保存するには、FSx for Windowsファイルサーバーを使用することをお勧めします。これにより、両方のサーバー間でシームレスな負荷分散が可能になります。
本番環境
このガイドのアーキテクチャは、本番環境の次の要件を満たすように設計されています。
ストレージタイプ— ウィンドウズファイルサーバ用 FSx
タイプ— 複数のアベイラビリティーゾーン
リソース/スループット— 1024 メガバイト
ストレージ— 1.2 ギガバイトのSSD
統合およびテスト環境
このガイドのアーキテクチャは、統合環境の次の要件を満たすように設計されています。
ストレージタイプ— ウィンドウズファイルサーバ用 FSx
タイプ— 複数のアベイラビリティーゾーン
リソース/スループット— 512 メガバイト
ストレージ— 512 ギガバイトのSSD
パフォーマンス
FSx for Windows File ServerのI/Oスループットは簡単に調整でき、監視ニーズに合わせてI/Oスループットダッシュボードを構築できます。また、運用チームがエンドユーザーのニーズに基づいてスループットを調整できるようにすることもできます。
バックアップとファイルリカバリ
すべての SAS データは、永続ストレージとして別の FSx for Windows ファイルサーバーに保存されます。 FSx for Windows ファイルサーバに保存されたデータには、次の 2 つのレベルのバックアップが実装されています。
日次バックアップ 30 日間の保持— これらのバックアップは S3 バケットに保持されます。Amazon FSx ボリュームが破損または失われた場合の復旧には、このスナップショットベースのバックアップを使用できます。
Microsoft VSS (ボリューム・シャドウ・コピー・サービス) を使用してバックアップを保存— FSx for Windows ファイルサーバ上のファイルは、1 日に 2 回、FSx for Windows ファイルサーバ上の特別なストレージパーティションへのバックアップ用にスナップショットが作成され、無期限に保持されます。バックアップは、FSx for Windows File Server上のVSSパーティションの使用可能なストレージ（合計ストレージ容量の最大10パーセント）に基づいて行われます。 エンドユーザーがFSx for Windows File Server上のファイルが破損または紛失した場合、SASターミナルサーバー上のWindowsファイルエクスプローラーから直接リストアを開始できます。
ディザスタリカバリ
このガイドのデカップリングアーキテクチャは、障害回復を念頭に置いて設計されています。Amazon FSx は 2 つの AWS アベイラビリティーゾーンにデプロイされます。 アクティブな FSx for Windows File Server が存在するアベイラビリティーゾーンが使用できなくなった場合、サービスは自動的にフェイルオーバーし、2 番目のアベイラビリティーゾーンからファイル共有サービスを提供します。
