기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
아키텍처 구성 요소
이 섹션에서는 다음과 같은 중요한 기능 아키텍처 구성 요소의 사양을 간략하게 설명합니다.
SAS 서버 -이 서버는 분석 처리를 위한 중앙 컴퓨팅 구성 요소이며 로컬 직접 연결 스토리지(DAS)를 포함합니다.
SAS 하위 버전 서버 -이 서버는 SAS의 중앙 집중식 버전 제어 시스템 역할을 합니다.
Amazon FSx for Windows File Server - SAS 서버와 터미널 서버 간에 스토리지를 공유하기 위한 SMB 파일 서버입니다. 최종 사용자는 사전 및 사후 처리된 데이터 파일을 FSx for Windows File Server에 저장하고 보관합니다.
터미널 서비스라고도 하는 Microsoft 원격 데스크톱 서비스(RDS) - RDS를 사용하면 최종 사용자가 SAS 클라이언트를 사용하여 SAS 서버에 액세스할 수 있습니다.
인프라 자동화 - AWS CodePipeline 및 AWS CodeCommit AWS CodeCommit과 함께 AWS 클라우드 개발 키트(AWS CDK)를 사용하여 인프라를 자동화할 수 있습니다. CodePipeline은 인프라 구성 요소를 프로비저닝하는 데 도움이 될 수 있습니다.CodePipeline은 코드를 릴리스하는 데 필요한 단계를 모델링, 시각화 및 자동화하기 위한 지속적인 제공 서비스입니다. 또한 CodePipeline은 공유 중앙 환경을 제공하고 로컬 시스템과 독립적인 인프라 관리를 지원합니다. CodeCommit은 프라이빗 Git 리포지토리를 호스팅하는 안전하고 확장성이 뛰어난 완전 관리형 소스 제어 서비스입니다. CodeCommit을 사용하여 AWS CDK 인프라 자동화 코드 및 파라미터를 저장할 수 있습니다.
참고
AWS CodeCommit 는 더 이상 신규 고객이 사용할 수 없습니다. 의 기존 고객은 평소와 같이 서비스를 계속 사용할 AWS CodeCommit 수 있습니다. 자세히 알아보기
환경 분리
다음 다이어그램은 SAS 통합과 SAS 프로덕션 환경을 분리하기 위한 아키텍처를 보여줍니다.
인프라 구성 요소
이 섹션에서는이 설명서의 권장 아키텍처에 필요한 인프라 구성 요소에 대한 개요를 제공합니다.
프로덕션 환경
프로덕션 환경에는 다음 인프라 구성 요소를 사용하는 것이 좋습니다.
유형 | 인스턴스 유형 | 리소스 |
SAS 서버 1개 | m6i.4xlarge | vCPUs(코어 8개) 64GB RAM |
Citrix 터미널 서버 2개 | m6i.4xlarge | vCPUs(코어 8개) 64GB RAM(예: Microsoft Office 및 Adobe Suite의 경우 사용자 세션당 1~2GB, SAS 클라이언트당 평균 500~1,024MB) 25명 이상의 사용자 향후 더 많은 터미널 서버로 확장 가능 |
SAS 하위 버전 서버 1개 | m6i.2xlarge | vCPUs 코어 4개 32GB RAM |
통합 환경
통합 환경에는 다음 인프라 구성 요소를 사용하는 것이 좋습니다.
유형 | 인스턴스 유형 | 리소스 |
SAS 서버 1개 | m6i.2xlarge | vCPUs(코어 4개) 32GB RAM |
터미널 서버 2개 | m6i.2xlarge
| vCPUs(코어 4개) 32GB RAM |
SAS 하위 버전 서버 1개 | m6i.xlarge | vCPUs(코어 2개) 16GB RAM |
SAS 서버용 로컬 스토리지
권장 아키텍처는 최신 Intel Xeon Scalable 프로세서를 기반으로 하는 M6i 인스턴스를 사용하고 AWS Nitro 시스템의 Nitro
서버 | 유형 | 용량 | 프로덕션 | 테스트 |
SAS 서버 | 스토리지 유형 | AWS 리소스/서비스 및 EBS 유형 | seq에 대한 요구 사항 IO(읽기/쓰기) | 프로덕션과 동일 |
SAS 서버 | 운영 체제 부팅 및 스왑 | EBS 200GB(gp3) | 낮은 요구 사항으로 인해 크기 조정과 관련이 없음 | 프로덕션과 동일 |
SAS 서버 | SASWORK | RAID 0의 EBS 2x 512GB(gp3/각 5,000 IOPS) | 8 * 150Mbps, 1200Mbps 또는 ~ 11.5Gbps M6i 인스턴스 지원 gp3 EBS 볼륨을 사용하는 12.5Gbps EBS 스토리지 대역폭 | 1x 1024GB 볼륨 gp3 5,000 IOPS |
SAS 서버 | SAS Software Depot 및 기타 보조 스토리지(SAS 설치 추가 포함) | EBS 125GB(gp3) | 낮은 요구 사항으로 인해 크기 조정과 관련이 없음 | 프로덕션과 동일 |
SAS 터미널 서버 | 운영 체제 부팅 및 스왑 | EBS 100GB(gp3) | 낮은 요구 사항으로 인해 크기 조정과 관련이 없음 | 프로덕션과 동일 |
SAS SVN 서버 | 운영 체제 부팅 및 스왑 | EBS 100GB(gp3) | 낮은 요구 사항으로 인해 크기 조정과 관련이 없음 | 100GB |
SAS SVN 서버 | 하위 버전 리포지토리 | EBS 1000GB(gp3) | Default | 운영 드라이브 외에 400GB |
공유 스토리지 인프라
FSx for Windows File Server를 SAS 서버와 Citrix 터미널 서버의 공유 스토리지 솔루션으로 사용하는 것이 좋습니다. 시스템 정보 또는 자동화 스크립트를 유지하기 위해 버킷이 필요한 경우가 아니면 추가 파일 스토리지에 S3 버킷을 사용할 필요가 없습니다.
FSx for Windows File Server에 프로젝트 코드의 하위 버전 체크아웃/작업 복사본을 저장할 수도 있습니다. SAS 하위 버전 서버는 리포지토리를 로컬에 저장합니다. 하위 버전 서버는 중앙 버전 제어 시스템 역할을 합니다.
FSx for Windows File Server를 사용하여 Citrix 터미널 서버 전체에 Windows 사용자 프로필을 저장하는 것이 좋습니다. 이렇게 하면 두 서버 모두에서 원활한 로드 밸런싱이 가능합니다.
프로덕션 환경
이 설명서의 아키텍처는 프로덕션 환경에 대한 다음 요구 사항을 충족하도록 설계되었습니다.
스토리지 유형 - FSx for Windows File Server
유형 - 여러 가용 영역
리소스/처리량 – 1,024MB
스토리지 - 1.2TB SSD
통합 및 테스트 환경
이 설명서의 아키텍처는 통합 환경에 대한 다음 요구 사항을 충족하도록 설계되었습니다.
스토리지 유형 - FSx for Windows File Server
유형 - 여러 가용 영역
리소스/처리량 – 512MB
스토리지 - 512GB SSD
성능
FSx for Windows File Server의 I/O 처리량은 쉽게 조정할 수 있으며 모니터링 요구 사항에 맞게 I/O 처리량 대시보드를 구축할 수 있습니다. 또한 운영 팀이 최종 사용자의 필요에 따라 처리량을 조정할 수 있도록 할 수도 있습니다.
백업 및 파일 복구
모든 SAS 데이터는 영구 스토리지로 별도의 FSx for Windows File Server에 상주합니다. FSx for Windows File Server에 저장된 데이터에는 두 가지 수준의 백업이 구현됩니다.
30일 동안 보관된 일일 백업 - 이러한 백업은 S3 버킷에 보관됩니다. Amazon FSx 볼륨이 손상되거나 손실된 경우이 스냅샷 기반 백업을 복구에 사용할 수 있습니다.
Microsoft Volume Shadow Copy Service(VSS)를 사용하여 보존된 백업 - FSx for Windows File Server의 파일은 FSx for Windows File Server의 특수 스토리지 파티션으로 백업하기 위해 1일 2회 스냅샷 처리되고 무기한 보존됩니다. 백업은 FSx for Windows File Server에서 VSS 파티션의 사용 가능한 스토리지(총 스토리지 공간의 최대 10%)를 기반으로 합니다. 최종 사용자가 FSx for Windows File Server에서 파일을 손상시키거나 분실한 경우 SAS 터미널 서버의 Windows File Explorer에서 직접 자체 복원을 시작할 수 있습니다.
재해 복구
이 안내서의 디커플링 아키텍처는 재해 복구를 염두에 두고 설계되었습니다. Amazon FSx는 두 AWS 가용 영역에 배포됩니다. 활성 FSx for Windows File Server가 상주하는 가용 영역을 사용할 수 없게 되면 서비스가 자동으로 장애 조치되고 두 번째 가용 영역에서 파일 공유 서비스를 제공합니다.
