Amazon FSx-এর পরিবার

এই লেসন শেষে তুমি পারবে

• EFS থাকার পরেও AWS কেন Amazon FSx দেয়, সেটা বোঝাতে, আর FSx-এর চারটা file system-এর নাম আর প্রত্যেকটা কোন কাজের জন্য বানানো, তা বলতে।
• FSx for Windows File Server বুঝিয়ে বলতে: SMB, NTFS permission, Active Directory, DFS Namespaces, SSD নাকি HDD, Single-AZ নাকি Multi-AZ, Linux আর অফিস থেকে ব্যবহার, আর S3-এ প্রতিদিনের backup।
• SMB, NFS আর Active Directory সহজ ভাষায় বোঝাতে, আর directory-তে পৌঁছানো না গেলে একটা file share-এর কী হয়, তা বলতে।
• FSx for Lustre বুঝিয়ে বলতে: HPC আর machine learning-এর parallel file system, scratch বনাম persistent, প্রতি TiB-তে throughput, আর S3 data repository কীভাবে input lazy-load করে আর ফল export করে।
• FSx for NetApp ONTAP (একটা system থেকেই NFS, SMB আর iSCSI, deduplication, compression, tiering, snapshot, clone, SnapMirror) আর FSx for OpenZFS (NFS, খুব কম latency, snapshot আর clone) বুঝিয়ে বলতে।
• পরীক্ষার যেকোনো scenario-তে EFS, চারটা FSx file system আর S3 File Gateway-এর মধ্যে বেছে নিতে, আর কোন keyword দেখে সিদ্ধান্ত নিলে তা যুক্তি দিয়ে বলতে।

#FSx কেন দরকার হলো

#EFS একটাই কাজ ঢাকে

Lesson 5.4-এ তুমি EFS দেখেছ: একটা managed shared file system, যেটা কয়েকটা AZ-এর অনেক EC2 instance একসাথে mount করে। একটা কাজে সে দারুণ: NFS দিয়ে Linux-এর shared file। Note সীমাটা সোজাসুজি বলে দেয়: EFS শুধু Linux সাপোর্ট করে। Windows-এ চলে না, Active Directory-র user বা Windows permission সে চেনে না, supercomputer-এর জন্য parallel file system না, আর NetApp বা ZFS-এর যে feature-এর ওপর কোম্পানিগুলো বছরের পর বছর কাজ সাজিয়েছে, সেগুলোও তার নেই।

অথচ কোম্পানিগুলোর data centre-এ আগে থেকেই আরও অনেক রকম file system চলছে: Windows file server, HPC-র জন্য Lustre cluster, NetApp storage array, ZFS server। AWS-এ আসার সময় তারা প্রতিটা application নতুন করে লিখে EFS বা S3-এ বসাতে চায় না। তারা চায় চেনা সেই file system-টাই, কিন্তু server, disk, patch আর failover-এর দেখাশোনা ছাড়া।

#চারটা managed file system

Amazon FSx ঠিক এটাই: পরিচিত, উঁচু performance-এর third-party file system AWS তোমার জন্য চালু করে দেয়, পুরোপুরি managed service হিসেবে। তুমি file system, size আর throughput বেছে দাও; server আর disk দেয় AWS, data replicate করে, নষ্ট hardware বদলায়, software patch করে, backup নেয়। পরিবারে চারজন সদস্য:

চারটাই থাকে তোমার VPC-র ভেতরে: প্রতিটা file system তোমার subnet-এ এক বা একাধিক elastic network interface পায়, আর client তার private address-এ পৌঁছায়। কোনোটাকেই public internet-এ খোলা যায় না। অফিস থেকে পৌঁছাতে হয় Site-to-Site VPN বা Direct Connect দিয়ে (lesson 10.10)।

#FSx for Windows File Server

#Server ছাড়াই একটা Windows file server

FSx for Windows File Server হলো পুরোপুরি managed একটা Windows file share drive, Windows Server-এর ওপর বানানো। Windows user আর application-এর কাছে এটা ঠিক সেই file server, যেটা তারা আগে থেকেই চেনে:

• File share-এর জন্য SMB protocol (version 2.0 থেকে 3.1.1), আর নিচে NTFS file system।
• Microsoft Active Directory-র সাথে যুক্ত: user-রা নিজেদের চেনা domain account দিয়েই login করে।
• File আর folder-এ Windows access control list (ACL), user quota, shadow copy (যে “Previous Versions” tab থেকে user নিজেই পুরোনো file ফেরত আনে), Windows-এর data deduplication, আর file access auditing।
• অনেক share আর file system-কে একটা path-এর নিচে আনতে DFS Namespaces (নিচে আছে)।
• Client: Windows Server 2008 আর Windows 7 থেকে পরের সব Windows, Linux EC2 instance (এরা cifs-utils দিয়ে SMB-তে mount করে), Amazon-এর virtual desktop, আর VMware Cloud on AWS।
• অফিসের network থেকে VPN বা Direct Connect দিয়ে পৌঁছানো যায়, আর অন্য VPC, account বা Region থেকে VPC peering বা transit gateway দিয়ে।

যে Windows application-এ এটা খুব মানায়: বিভাগ আর user-এর share, home directory, IIS-এর web content, content management system, ব্যবসার application, media processing, আর SQL Server, যে তার database file একটা continuously available SMB share-এ রাখতে পারে।

#SMB, NFS আর Active Directory সহজ ভাষায়

এই তিনটা শব্দ প্রতিটা FSx আর Storage Gateway প্রশ্নে আসে, তাই jargon ছাড়া একবার বুঝে নিই।

• NFS (Network File System) হলো Linux আর Unix-এর file share করার ভাষা। অফিসে পাঁচটা Linux কম্পিউটার: ১ নম্বর কম্পিউটারের একটা folder বাকি চারটা এমনভাবে ব্যবহার করে, যেন সেটা তাদের নিজেদের disk-এই আছে। এটাই NFS। EFS, FSx for OpenZFS আর FSx for ONTAP এই ভাষায় কথা বলে।
• SMB (Server Message Block) হলো Windows-এর file আর printer share করার ভাষা। Windows-এ কখনো কোনো folder-এ right-click করে Properties → Sharing → Share করে থাকলে, তুমি SMB-ই ব্যবহার করেছ। অফিসে একটা কেন্দ্রীয় Windows server থেকে সবার PC-তে folder share করতে SMB লাগে। FSx for Windows আর FSx for ONTAP এই ভাষায় কথা বলে।
• Active Directory (AD) হলো Windows network-এর কেন্দ্রীয় পরিচয় ব্যবস্থা: user কারা, তাদের password, তাদের group, আর কে কী ব্যবহার করতে পারবে।

FSx for Windows তৈরির সময়েই একটা directory-তে যুক্ত হয়। দুটো উপায়:

• AWS Managed Microsoft AD (AWS Directory Service): তোমার VPC-তে domain controller চালায় AWS। এটা তোমার অফিসের domain-কে trust করতে পারে।
• নিজের self-managed AD: অফিসে বা EC2-তে তুমি আগে থেকে যে domain controller চালাও।

Active Directory ছাড়া file system বুঝতেই পারে না কে login করছে। FSx যদি সব domain controller-এর সাথে যোগাযোগ হারায়, নতুন session ব্যর্থ হয়, আর directory আবার নাগালে না আসা পর্যন্ত file system-কে Misconfigured দেখাতে পারে। তাই domain controller রাখো AWS-এর ভেতরে, file system-এর কাছাকাছি (একই VPC-তে, বা ভরসাযোগ্য link-এর ওপারে), শুধু অফিসের VPN-এর অন্য মাথায় না। Directory Service নিয়ে বিস্তারিত আছে chapter 20-এ (Identity Center আর Directory Service)।

#DFS Namespaces: অনেক share, একটা path

DFS (Microsoft Distributed File System) Namespaces অনেক file server-এর folder একটা গোছানো path-এর নিচে দেখায়, যেমন \\corp.example.com\files\finance আর \\corp.example.com\files\design। কোন folder কোন server-এ আছে, user-কে তা জানতেই হয় না, আর admin কারো mapped drive না বদলেই একটা folder অন্য file system-এ সরিয়ে দিতে পারে। FSx for Windows-এর প্রতিটা deployment type-এ DFS Namespaces চলে।

Slide-এর “শত শত PB” FSx for Windows এভাবেই ছোঁয়। একটা file system-এ সর্বোচ্চ ৬৪ TiB; DFS Namespaces অনেকগুলো file system-কে জুড়ে এমনভাবে দেখায়, যেন একটাই বিশাল share। (DFS Replication, যেটা server-এর মধ্যে folder copy করে, চলে শুধু পুরোনো Single-AZ 1 type-এ; Multi-AZ নিজেই replicate করে।)

#Size, গতি আর storage-এর ধরন

File system বানানোর সময় তুমি তিনটা সংখ্যা বেছে দাও, পরে বাড়াতেও পারো:

• Storage capacity: SSD হলে ৩২ GiB থেকে, HDD হলে ২,০০০ GiB থেকে, দুটোই ৬৪ TiB পর্যন্ত।
• Throughput capacity: প্রতি file system-এ 8 MB/s থেকে 12,288 MB/s (প্রায় ১২ GB/s) পর্যন্ত। এটা file server-এর memory আর network-ও ঠিক করে, তাই performance-এর বেশিরভাগটা এটার ওপরই নির্ভর করে।
• SSD IOPS: default হিসেবে SSD-র প্রতি GiB-তে ৩, আর চাইলে ৪,০০,০০০ পর্যন্ত provision করা যায়।

দুই ধরনের storage:

#Single-AZ নাকি Multi-AZ

Multi-AZ failover Windows client নিজেরাই অনুসরণ করে, কারণ DNS নাম একই থাকে। Linux client করে না: file system preferred server-এ ফিরে (failback) গেলে তবেই তারা আবার চলে। “কোথায় গোলমাল হয়” অংশের জন্য কথাটা মনে রেখো।

#Backup

FSx for Windows প্রতিদিন একটা automatic daily backup নেয়, টেকসইভাবে রাখে S3-এ (FSx-এর নিজের সামলানো জায়গায়, তোমার দেখা কোনো bucket-এ না)। Backup incremental আর file-system-consistent (Windows Volume Shadow Copy Service দিয়ে)। কতদিন রাখবে: ০ থেকে ৯০ দিন (console-এ default ৩০; ০ দিলে daily backup বন্ধ)। চাইলে user-initiated backup নিতে পারো, যেটার মেয়াদ কখনো শেষ হয় না, backup অন্য Region-এ copy করতে পারো, আর AWS Backup দিয়ে সব এক জায়গা থেকে সামলাতে পারো (ঘণ্টায় ঘণ্টায় schedule, লম্বা retention, অন্য account-এ copy)। Restore করলে সবসময় একটা নতুন file system তৈরি হয়।

#FSx for Lustre

#Lustre জিনিসটা কী

Lustre নামটা এসেছে “Linux” + “cluster” থেকে। এটা একটা parallel distributed file system, বড় মাপের computing-এর জন্য বানানো: supercomputer, render farm, model training। সাধারণ file server-এ প্রতিটা file একটা server দিয়েই যায়। Lustre প্রতিটা file টুকরো টুকরো (stripe) করে অনেক storage server-এ ছড়িয়ে রাখে, আর প্রতিটা client একসাথে সবার সাথে কথা বলে। Storage server যত বাড়াবে, মোট গতিও তত বাড়বে।

এজন্যই FSx for Lustre ব্যবহার হয় machine learning, high performance computing (HPC), video processing, financial modelling আর chip design (electronic design automation)-এ: যেখানে হাজারো core লাখ লাখ file, প্রায়ই একই file, যত দ্রুত সম্ভব পড়ে আর লেখে।

• গতি: শত শত GB/s পর্যন্ত (EFA networking দিয়ে আরও বেশি), লাখ লাখ IOPS, millisecond-এরও কম latency। Throughput ঠিক হয় প্রতি TiB storage ধরে (নিচে)।
• Client: শুধু Linux, open-source Lustre client দিয়ে। EC2 instance, EKS-এর container, আর VPN বা Direct Connect দিয়ে অফিসের Linux server (অফিসের cluster থেকে বাড়তি কাজ cloud-এ পাঠাতে, যাকে “cloud bursting” বলে)।
• Storage class: ছোট, random file operation-ওয়ালা কম latency আর বেশি IOPS-এর কাজে SSD; বড়, sequential file operation-ওয়ালা throughput-নির্ভর কাজে HDD (চাইলে SSD read cache সহ); আর ২০২৪-এর শেষ থেকে Intelligent-Tiering, যেটা elastic আর ঠান্ডা data নিজে থেকেই সস্তা tier-এ সরায়।
• একটাই AZ। একটা Lustre file system থাকে একটা Availability Zone-এ। অন্য AZ-এর client-ও mount করতে পারে, কিন্তু cross-AZ traffic-এর খরচ আর latency দিতে হয়।

#Scratch নাকি persistent

Lustre file system বানানোর সময় সবচেয়ে গুরুত্বপূর্ণ সিদ্ধান্ত হলো তার deployment type:

একটা হিসাব করে দেখি: ২৪ TiB-এর একটা Persistent 2 SSD file system, প্রতি TiB-তে 250 MB/s, মানে 24 × 250 = 6,000 MB/s, প্রায় ৬ GB/s baseline throughput। এই গতিতে ৩৬ TB-র একটা dataset একবার পুরো পড়তে লাগে মোটামুটি 36,000,000 MB ÷ 6,000 MB/s = 6,000 সেকেন্ড, মানে প্রায় ১ ঘণ্টা ৪০ মিনিট।

#S3-এর সাথে নিখুঁত জোড়া

Lustre পরীক্ষার প্রিয় হওয়ার কারণ S3-এর সাথে তার link। Note কথাটা সহজে বলে: S3-এর data file system-এ এনে process করো, তারপর আবার S3-তেই রেখে দাও।

1. তুমি একটা data repository association বানাও: /fsx/scenes-এর মতো একটা directory যুক্ত হয় s3://scenes-example/-এর মতো একটা S3 prefix-এর সাথে। (একটা file system-এর একাধিক থাকতে পারে।)
2. Lustre শুধু metadata আনে (নাম, size, permission)। Bucket যত বড়ই হোক, object-গুলো কয়েক মিনিটে file হয়ে দেখা দেয়।
3. Lazy loading: কোনো client প্রথমবার একটা file পড়লে Lustre তার content S3 থেকে এনে নিজের কাছে রেখে দেয়। প্রথম read একটু ধীর; পরের প্রতিটা read, যেকোনো client-এর, আসে Lustre থেকে পুরো গতিতে। (চাইলে job শুরুর আগেই file আগাম load করে রাখা যায়।)
4. Automatic import চালু থাকলে bucket-এর নতুন, বদলানো বা মুছে ফেলা object নিজে থেকেই file system-এ দেখা যায়।
5. Automatic export (বা job শেষে একটা export data repository task) দিয়ে নতুন আর বদলানো file আবার S3-এ object হয়ে লেখা হয়।
6. যে file আগেই S3-এ নিরাপদে আছে, জায়গা খালি করতে Lustre সেগুলো release করতে পারে; আবার পড়লে আবার lazy-load হয়।

তাই S3 থাকে টেকসই, সস্তা data lake, আর Lustre তার সামনের দ্রুত কাজের টেবিল। Slide এটাকে বলে “S3-কে file system হিসেবে পড়া” আর “হিসাবের ফল আবার S3-এ লেখা”।

#FSx for NetApp ONTAP

#NetApp storage, চালায় AWS

NetApp এমন storage array বানায়, যেগুলো অনেক কোম্পানির data centre-এ চলে, আর ONTAP তাদের storage operating system। FSx for NetApp ONTAP তোমাকে সেই একই ONTAP দেয়, চালায় AWS। Note ব্যবহারটা আগে বলে: তোমার data centre-এ NetApp storage আছে, আর তুমি সেটা AWS-এ আনতে চাও। আরও বড় করে বললে, যেকোনো NAS workload application না বদলে সরাতে চাইলে এটা মানায়।

এর সবচেয়ে বড় গুণ, এটা multi-protocol: একটা file system থেকেই দেয়

• Linux আর macOS-কে NFS,
• Windows-কে SMB (Active Directory সহ),
• Database আর যেসব server কাঁচা disk চায় তাদের iSCSI block volume (আর নতুন যোগ হওয়া NVMe over TCP), ঠিক SAN-এর মতো।

একই volume চাইলে একসাথে NFS আর SMB দুটো দিয়েই share করা যায়। এটা Linux, Windows আর macOS client, VMware Cloud on AWS, Amazon-এর virtual desktop, আর EC2, ECS ও EKS-এর সাথে কাজ করে, AWS-এর ভেতরে বা অফিস থেকে।

#জায়গা আর টাকা বাঁচানো

• Deduplication, compression আর compaction: একই রকম block জমা হয় একবারই, বাকিটা compress হয়, ছোট ছোট block একসাথে গুছিয়ে রাখা হয়। Note এটাকেই বড় সুবিধা বলে: storage-এর খরচ বাঁচে।
• দুটো tier: গরম data-র জন্য provision করা একটা SSD tier, আর ঠান্ডা data-র জন্য elastic একটা capacity pool। Tiering policy দিয়ে (যেমন Auto, default cooling period ৩১ দিন) কেউ না ছোঁয়া block নিজে থেকেই সস্তা pool-এ নেমে যায়, আবার পড়লে ফিরে আসে। SSD-র দাম দাও শুধু গরম অংশটুকুর। Slide-এর “storage নিজে থেকেই বাড়ে-কমে” কথাটার মানে এটাই: capacity pool তোমার data-র সাথে বাড়ে-কমে, আর SSD tier হলো তোমার বেছে দেওয়া একটা size।
• Snapshot, যেটা data না বদলানো পর্যন্ত প্রায় কোনো জায়গাই নেয় না, আর point-in-time তাৎক্ষণিক clone (FlexClone): কয়েক সেকেন্ডে একটা volume-এর লেখা-যায় এমন copy, না-বদলানো সব block ভাগাভাগি করে। আসল data-র ওপর নতুন release test করার জন্য একদম উপযুক্ত।
• SnapMirror replication: NetApp-এর নিজস্ব replication, অফিসের NetApp থেকে migration-এর জন্য (একবার পুরোটা copy, তারপর শুধু পরিবর্তন, তারপর বদল) আর অন্য Region-এ disaster recovery-র জন্য।
• আরও আছে: Single-AZ বা Multi-AZ high availability, automatic daily backup, compliance-এর জন্য write-once (WORM) volume, আর antivirus scanning।

#FSx for OpenZFS

#ZFS, চালায় AWS

ZFS একটা file system, প্রথমে বানিয়েছিল Sun Microsystems; storage admin-রা একে ভালোবাসে প্রতিটা block-এ checksum, সস্তা snapshot, clone আর compression-এর জন্য। OpenZFS তার open-source ধারা। Note বলে দেয় কাদের জন্য: যাদের local server-এ আগে থেকেই ZFS চলছে। FSx for OpenZFS তাদের সেই workload, বা যেকোনো Linux file server, application বা অভ্যাস না বদলেই AWS-এ আনতে দেয়।

• শুধু NFS: version v3, v4.0, v4.1 আর v4.2। SMB নেই, iSCSI নেই। Client: Linux, Windows আর macOS-এর NFS client, VMware Cloud on AWS, Amazon-এর virtual desktop, EC2, ECS আর EKS।
• খুব দ্রুত: slide বলে ১০ লাখ IOPS পর্যন্ত, ০.৫ ms-এর কম latency-তে; AWS-এর এখনকার documentation বলে ২০ লাখ IOPS পর্যন্ত, latency কয়েকশো microsecond (memory আর NVMe cache থেকে), আর cache-এর data-র জন্য প্রায় ২১ GB/s পর্যন্ত।
• Snapshot: প্রায় সাথে সাথে, point-in-time, file system-এর ওপরেই থাকে। User নিজেই .zfs/snapshot-এর নিচে খুলে দেখতে পারে, আর পুরো একটা volume একটা snapshot-এ ফিরিয়ে নেওয়া যায়।
• Clone: একটা snapshot থেকে বানানো নতুন volume সাথে সাথেই তৈরি, না-বদলানো block ভাগাভাগি করে, test environment-এর জন্য আদর্শ।
• Compression (Zstandard, বা আরও দ্রুত হালকা একটা algorithm) storage খরচ কমায়, প্রায়ই গতিও বাড়ায়। ONTAP-এর মতো না, FSx for OpenZFS deduplication করে না।
• Availability: Multi-AZ (দুই AZ জুড়ে HA) বা Single-AZ (HA), দুটোই প্রায় ৬০ সেকেন্ডে failover করে, নয়তো Single-AZ (non-HA), যেটা প্রায় ৩০ মিনিটে নিজে সেরে ওঠে। Automatic daily backup যায় S3-এ।
• পাশের কথা (২০২৪–২০২৫): elastic একটা Intelligent-Tiering storage class, যেটা ঠান্ডা data নিজে থেকে সস্তা tier-এ সরায়, আর S3 Access Points, যেটা দিয়ে S3-ভিত্তিক tool OpenZFS volume-কে object হিসেবে পড়তে পারে। পরীক্ষা এর কোনোটাই আশা করে না।

#EFS আর FSx পরিবারের মধ্যে বেছে নেওয়া

Note-এর তুলনার সারিগুলো, একটু নিখুঁত করে:

• FSx for Windows: file storage; পৌঁছানো যায় Windows EC2 (আর SMB দিয়ে Linux) আর অফিসের server থেকে; Windows environment, SMB, Active Directory, IIS server-এর জন্য।
• FSx for Lustre: file storage; দ্রুত গতিতে পৌঁছায় Linux EC2 (আর VPN বা Direct Connect দিয়ে অফিসের Linux); HPC, big data, machine learning, S3-এর data process করার জন্য।

দুই প্রতিবেশীকে আলাদা রাখো:

• S3 File Gateway (lesson 12.3) অফিসের server-কে একটা NFS বা SMB share দেয়, যার file হয়ে যায় S3-এর object। FSx file রাখে একটা file system-এ। Data-কে শেষে S3-এ পৌঁছাতে হলে gateway ভাবো; user-দের শুধু একটা managed file server দরকার হলে FSx ভাবো।
• Amazon FSx File Gateway ছিল branch office-এর জন্য FSx for Windows-এর সামনে একটা local cache। ২৮ অক্টোবর ২০২৪ থেকে নতুন গ্রাহকদের জন্য এটা বন্ধ (lesson 10.11); নতুন design-এ অফিস সরাসরি VPN বা Direct Connect দিয়ে FSx for Windows-এ পৌঁছায়, নয়তো DFS আর একটা local server ব্যবহার করে।

কারণ পড়ার আগে প্রতিটা scenario নিজে চেষ্টা করো:

#সব FSx file system-এ যা একই রকম

• VPC-র ভেতরে, কখনো public না। প্রতিটা file system-এর elastic network interface থাকে তোমার subnet-এ (Multi-AZ-এ দুটো)। কে port-এ পৌঁছাতে পারবে তা ঠিক করে security group (SMB TCP 445, NFS TCP 2049, Lustre TCP 988, iSCSI TCP 3260)। ওই network interface বদলাবে না, মুছবেও না।
• Encryption। জমা data (at rest) সবসময় encrypt হয় KMS key দিয়ে (AWS managed key বা তোমার নিজের)। চলার পথে (in transit): Windows-এ SMB Kerberos encryption, আর Lustre persistent, ONTAP ও OpenZFS-এ সাপোর্ট করা EC2 instance (Nitro) থেকে নিজে থেকেই encryption।
• IAM নিয়ন্ত্রণ করে API (কে file system বানাবে, বদলাবে, backup নেবে বা মুছবে), কে একটা file পড়বে তা না; সেটা NTFS ACL, POSIX permission বা ONTAP-এর নিজের নিয়ম।
• Backup incremental, আর Windows, ONTAP, OpenZFS ও Lustre persistent-এ জমা থাকে S3-এ; AWS Backup সবগুলো সামলাতে পারে, অন্য Region আর অন্য account-এ copy সহ।
• Data আনা: DataSync অফিসের NFS বা SMB server থেকে (বা S3 আর EFS থেকে) যেকোনো FSx file system-এ copy করে, permission অটুট রেখে (lesson 10.11); ONTAP-এর আছে SnapMirror, আর Lustre-এর S3 repository। সব service-এর পুরো storage তুলনা আছে lesson 12.4-এ।
• দাম। EFS-এর মতো না, এখানে বেশিরভাগ টাকা দাও যতটা provision করো তার জন্য: storage (GB-month), throughput capacity (MB/s-month), কখনো বাড়তি SSD IOPS, আর backup storage। ব্যতিক্রম ONTAP-এর capacity pool আর Intelligent-Tiering class, যেখানে যতটা জমা রাখো ততটার দাম।

#কোথায় গোলমাল হয়

#System design-এ FSx

• Windows application তুলে এনে বসানো। IIS web farm, Windows app আর EC2-তে SQL Server আগের মতোই SMB share আর Active Directory ব্যবহার করে, ভঙ্গুর একটা file server-এর বদলে Multi-AZ FSx for Windows দিয়ে।
• Hybrid অফিস। ঢাকা আর চট্টগ্রামের কর্মীরা Site-to-Site VPN বা Direct Connect দিয়ে একই FSx for Windows share map করে, আর DFS Namespaces আড়াল করে রাখে কোন বিভাগ কোন file system-এ।
• দরকারমতো HPC। Data থাকে S3-এ; প্রতিটা job-এর জন্য একটা scratch Lustre file system বানানো হয়, bucket-এর সাথে যুক্ত হয়, একঝাঁক Spot instance সেটা ব্যবহার করে, ফল export হয়, তারপর মুছে ফেলা হয়। দ্রুত tier-এর টাকা দাও শুধু হিসাব চলার সময়টুকুর (chapter 4-এর Spot Instance আর EFA এখানে খাপ খায়)।
• পুরো data centre সরানো। একটা NetApp-এর জগৎ SnapMirror দিয়ে FSx for ONTAP-এ সরে আসে, NFS, SMB আর iSCSI client, storage efficiency আর team-এর tool সব রেখে; disaster recovery-র জন্য দ্বিতীয় একটা Region-এ replicate হয়।
• দ্রুত dev আর test। ONTAP বা OpenZFS-এর clone প্রত্যেক developer বা tester-কে কয়েক সেকেন্ডে production data-র একটা পুরো, লেখা-যায় এমন copy দেয়, প্রায় কোনো বাড়তি জায়গা ছাড়াই।
• সাধারণ Linux sharing-এর জন্য EFS-ই থাকুক। তিনটা AZ-এর একটা WordPress farm-এর জন্য EFS সহজ আর elastic; নির্দিষ্ট কোনো protocol, feature বা performance লাগলে তবেই FSx উত্তর।

#নিজে করে দেখো

এই command-গুলো আসল, টাকা লাগা file system বানায়; একটা test VPC ব্যবহার করো, আর শেষে মুছে দিয়ো। নিচের ID-গুলো উদাহরণ।

# 1. FSx for Windows File Server: Multi-AZ, SSD, joined to AWS Managed Microsoft AD
aws fsx create-file-system --file-system-type WINDOWS \
  --storage-capacity 32 --storage-type SSD \
  --subnet-ids subnet-0aaa1111example subnet-0bbb2222example \
  --security-group-ids sg-0123abcdexample \
  --windows-configuration "ActiveDirectoryId=d-1234567890,DeploymentType=MULTI_AZ_1,PreferredSubnetId=subnet-0aaa1111example,ThroughputCapacity=32,AutomaticBackupRetentionDays=30"
#   "FileSystemId": "fs-0123456789abcdef0",
#   "Lifecycle": "CREATING",
#   "DNSName": "amznfsxabcd1234.corp.example.com"

# 2. FSx for Lustre: scratch, linked to an S3 bucket through a data repository association
aws fsx create-file-system --file-system-type LUSTRE \
  --storage-capacity 1200 --subnet-ids subnet-0aaa1111example \
  --lustre-configuration DeploymentType=SCRATCH_2
aws fsx create-data-repository-association --file-system-id fs-0fedcba9876543210 \
  --file-system-path /scenes --data-repository-path s3://scenes-example/ \
  --s3 "AutoImportPolicy={Events=[NEW,CHANGED,DELETED]},AutoExportPolicy={Events=[NEW,CHANGED,DELETED]}"

# 3. See what you have: type, state, deployment type and DNS name
aws fsx describe-file-systems \
  --query 'FileSystems[].{Id:FileSystemId,Type:FileSystemType,State:Lifecycle,DNS:DNSName}' --output table
#   |  DNS                                       |  Id                    | State     | Type     |
#   |  amznfsxabcd1234.corp.example.com          |  fs-0123456789abcdef0  | AVAILABLE | WINDOWS  |
#   |  fs-0fedcba9876543210.fsx.ap-south-1.amazonaws.com | fs-0fedcba9876543210 | AVAILABLE | LUSTRE |

# 4. Mount them
#    Windows (PowerShell / cmd):
#      net use Z: \\amznfsxabcd1234.corp.example.com\share
#    Linux, the same Windows share over SMB:
sudo mount -t cifs //amznfsxabcd1234.corp.example.com/share /mnt/share \
  -o vers=3.0,sec=krb5,cruid=$(id -u)
#    Linux, the Lustre file system (needs the Lustre client; the mount name comes from describe-file-systems):
sudo mount -t lustre -o relatime,flock \
  fs-0fedcba9876543210.fsx.ap-south-1.amazonaws.com@tcp:/abcdefgh /fsx

# 5. Lustre: export results to S3 at the end of a job, if automatic export is off
aws fsx create-data-repository-task --file-system-id fs-0fedcba9876543210 \
  --type EXPORT_TO_REPOSITORY --paths renders/ep01 --report Enabled=false

# 6. OpenZFS: snapshot a volume, then create a clone from it
aws fsx create-snapshot --volume-id fsvol-0123456789example --name pre-upgrade
aws fsx create-volume --volume-type OPENZFS --name test-clone-1 \
  --open-zfs-configuration "ParentVolumeId=fsvol-0aaaaaaaaaexample,OriginSnapshot={SnapshotARN=arn:aws:fsx:ap-south-1:111122223333:snapshot/fsvol-0123456789example/fsvolsnap-0abc1234example,CopyStrategy=CLONE}"

# 7. A user-initiated backup (never expires), then clean up
aws fsx create-backup --file-system-id fs-0123456789abcdef0
aws fsx delete-file-system --file-system-id fs-0fedcba9876543210

Domain-এ যুক্ত একটা Windows instance-এ \\amznfsxabcd1234.corp.example.com\share Explorer-এ যেকোনো file server-এর মতোই খোলে; একটা folder-এ right-click → Properties → Security খুললে NTFS permission দেখা যায়, আর shadow copy চালু থাকলে Previous Versions tab-এ পুরোনো version। Lustre mount-এ lfs df -h /fsx দেখায় file system কোন কোন storage server-এ ছড়ানো।

#সারসংক্ষেপ

মূল কথাগুলো

• EFS হলো NFS দিয়ে shared Linux storage। বাকি সবকিছুর জন্য Amazon FSx পরিচিত third-party file system পুরোপুরি managed service হিসেবে চালু করে: Windows File Server, Lustre, NetApp ONTAP, OpenZFS। সবগুলো থাকে তোমার VPC-তে, at rest সবসময় encrypt, আর অফিস থেকে পৌঁছায় VPN বা Direct Connect দিয়ে।
• FSx for Windows File Server: SMB, NTFS, Active Directory (AWS Managed বা self-managed), ACL, user quota, shadow copy, DFS Namespaces; Linux থেকেও mount করা যায়। SSD (latency-সংবেদনশীল) বা HDD (সাধারণ share)। প্রতি file system-এ ৬৪ TiB আর প্রায় ১২ GB/s পর্যন্ত; DFS অনেকগুলোকে জোড়ে। Multi-AZ ৩০ সেকেন্ডের কম সময়ে failover করে; Single-AZ ফেরে প্রায় ৩০ মিনিটে। S3-এ প্রতিদিনের backup, ০–৯০ দিন।
• SMB = Windows-এর file sharing, NFS = Linux-এর file sharing, AD = user, password আর permission-এর একটাই কেন্দ্র। AD নাগালে না থাকলে Windows share নতুন user যাচাই করতে পারে না।
• FSx for Lustre (“Linux + cluster”): HPC, ML, video, finance, chip design-এর parallel file system, শত শত GB/s, millisecond-এর কম latency, শুধু Linux, একটা AZ। Scratch: সাময়িক, replicate হয় না, প্রতি TiB-তে 200 MB/s আর প্রায় ৬ গুণ burst, সবচেয়ে সস্তা। Persistent: AZ-এর ভেতরে replicate, কয়েক মিনিটে server বদল, প্রতি TiB-তে 125–1,000 MB/s। S3 data repository: আগে metadata, প্রথম read-এ content lazy-load, auto import, আর ফল আবার S3-এ export।
• FSx for NetApp ONTAP: multi-protocol NFS + SMB + iSCSI, dedup, compression, SSD tier + elastic capacity pool, snapshot, তাৎক্ষণিক clone, SnapMirror দিয়ে migration আর DR, Multi-AZ।
• FSx for OpenZFS: শুধু NFS v3–v4.2, কয়েকশো microsecond-এ ২০ লাখ IOPS পর্যন্ত, snapshot, clone, compression (dedup নেই), Multi-AZ বা Single-AZ।
• Keyword: SMB / Windows / AD / DFS → Windows; HPC / ML / S3 → Lustre; dedup / compression / multi-protocol / NetApp → ONTAP; ZFS / snapshot / clone → OpenZFS; একাধিক AZ-এ Linux → EFS; অফিস থেকে S3 + NFS/SMB → S3 File Gateway।

নিজেকে যাচাই করো: Amazon FSx-এর পরিবার৩০টি প্রশ্ন