Architecture components
This section outlines the specifications of the following important functional architecture components:
SAS server – This server is the central compute component for analytics processing and includes local direct-attached storage (DAS).
SAS subversion server – This server acts as the centralized version control system for SAS.
Amazon FSx for Windows File Server – This is an SMB file server for sharing storage between the SAS server and terminal servers. End users store and archive their pre- and post-processed data files on FSx for Windows File Server.
Microsoft Remote Desktop Services (RDS), also known as Terminal Services – RDS allows end users to access SAS servers by using a SAS client.
Infrastructure automation – You can use the AWS Cloud Development Kit (AWS CDK) with AWS CodePipeline and AWS CodeCommit to automate your infrastructure. CodePipeline can help you provision your infrastructure components. CodePipeline is a continuous delivery service for modelling, visualizing, and automating the steps required to release code. Additionally, CodePipeline provides a shared central environment and enables infrastructure management that's independent from local machines. CodeCommit is a secure, highly scalable, fully managed source control service that hosts private Git repositories. You can use CodeCommit to store AWS CDK infrastructure automation code and parameters.
Note
AWS CodeCommit is no longer available to new customers. Existing customers of AWS CodeCommit can continue to use the service as normal. Learn more
Environment separation
The following diagram shows an architecture for separating a SAS integration and SAS production environment.
Infrastructure components
This section provides an overview of the infrastructure components that are required for the recommended architecture in this guide.
Production environment
We recommend that you use the following infrastructure components for your production environment.
Type | Instance type | Resources |
1 SAS server | m6i.4xlarge | 16 vCPUs (8 cores) 64 GB RAM |
2 Citrix terminal servers | m6i.4xlarge | 16 vCPUs (8 cores) 64 GB RAM (for example, 1–2 GB per user session for Microsoft Office and Adobe Suite and 500–1024 MB per SAS client on average) 25+ users Potential to scale out with more terminal servers in the future |
1 SAS subversion server | m6i.2xlarge | 8 vCPUs 4 cores 32 GB RAM |
Integration environment
We recommend that you use the following infrastructure components for your integration environment.
Type | Instance type | Resources |
1 SAS server | m6i.2xlarge | 8 vCPUs (4 cores) 32 GB RAM |
2 terminal servers | m6i.2xlarge
| 8 vCPUs (4 cores) 32 GB RAM |
1 SAS subversion server | m6i.xlarge | 4 vCPUs (2 cores) 16 GB RAM |
Local storage for SAS servers
The recommended architecture uses M6i instances based on the latest Intel Xeon Scalable processors and uses the Nitro Hypervisor from the AWS Nitro System
Server | Type | Capacity | Production | Testing |
SAS server | Storage type | AWS resource/service and EBS type | Requirement on seq. IO (read/write) | Same as production |
SAS server | Operating system boot and swap | EBS 200 GB (gp3) | Not relevant for sizing due to low requirements | Same as production |
SAS server | SASWORK | EBS 2x 512 GB (gp3/each 5,000 IOPS) in RAID 0 | 8 * 150 Mbps, 1200 Mbps or ~ 11.5 Gbps M6i instance support 12.5 Gbps EBS storage bandwidth with gp3 EBS volumes | 1x 1024 GB volume gp3 5,000 IOPS |
SAS server | SAS Software Depot and other auxiliary storage (to include SAS install in addition) | EBS 125 GB (gp3) | Not relevant for sizing due to low requirements | Same as production |
SAS terminal server | Operating system boot and swap | EBS 100 GB (gp3) | Not relevant for sizing due to low requirements | Same as production |
SAS SVN server | Operating system boot and swap | EBS 100 GB (gp3) | Not relevant for sizing due to low requirements | 100 GB |
SAS SVN server | Subversion repositories | EBS 1000 GB (gp3) | Default | 400 GB in addition to ops drive |
Shared storage infrastructure
We recommend using FSx for Windows File Server as a shared storage solution for your SAS server and the Citrix terminal servers. You don't have to use S3 buckets for any additional file storage, unless you need the bucket for maintaining system information or automation scripts.
You can also store the subversion checkout/working copy of project code on FSx for Windows File Server. The SAS subversion server stores the repositories locally. The subversion server acts as the central version control system.
We recommend that you use FSx for Windows File Server to store Windows user profiles across your Citrix terminal servers. This will enable seamless load balancing across both servers.
Production environment
The architecture in this guide is designed to meet the following requirements for the production environment:
Storage type – FSx for Windows File Server
Type – Multiple Availability Zones
Resource/throughput – 1024 MB
Storage – 1.2 TB SSD
Integration and testing environment
The architecture in this guide is designed to meet the following requirements for the integration environment:
Storage type – FSx for Windows File Server
Type – Multiple Availability Zones
Resource/throughput – 512 MB
Storage – 512 GB SSD
Performance
The I/O throughput for FSx for Windows File Server is easy to adjust, and you can build I/O throughput dashboards to meet your monitoring needs. You can also enable the operations team to adjust throughput based on end-user needs.
Back up and file recovery
All SAS data resides on a separate FSx for Windows File Server as persistent storage. There are two levels of backup implemented on the data stored in FSx for Windows File Server:
Daily backups retained for 30 days – These backups are retained in an S3 bucket. You can use this snapshot-based backup for recovery if an Amazon FSx volume is corrupted or lost.
Backups retained using Microsoft Volume Shadow Copy Service (VSS) – Files on the FSx for Windows File Server are snapshotted for backup to a special storage partition on the FSx for Windows File Server twice per day and retained indefinitely. The backup is based on available storage of the VSS partition on FSx for Windows File Server (up to 10 percent of total storage space). If end users corrupt or lose a file on FSx for Windows File Server, they can initiate their own restore directly from Windows File Explorer on the SAS terminal servers.
Disaster recovery
The decoupling architecture in this guide is designed with disaster recovery in mind. Amazon FSx is deployed across two AWS Availability Zones. If the Availability Zone where the active FSx for Windows File Server resides become unavailable, then the service automatically fails over and provides the file sharing services from the second Availability Zone.
