Storage Gateway: File, Volume আর Tape

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

• কোম্পানিগুলো কেন hybrid storage চালায় তা বোঝাতে, AWS-এর প্রতিটা storage service-কে block / file / object-এর ম্যাপে বসাতে, আর বলতে পারবে কেন অফিসে S3 ব্যবহার করতে gateway লাগে, অথচ EFS-এর জন্য লাগে না।
• Storage Gateway পরিবারের প্রত্যেক সদস্যকে চিনতে (S3 File Gateway, FSx File Gateway, cached আর stored mode-এর Volume Gateway, Tape Gateway): অফিসে কে কোন protocol বলে, AWS-এ data কোথায় থাকে, আর AWS সেই data দিয়ে কী করতে পারে।
• Gateway-এর local cache আর upload buffer কী করবে আগেই বলে দিতে: write-back, cache hit আর miss, eviction, link outage-এ cache ভরে যাওয়া, পুরোনো তালিকা, আর dirty data কেন এত গুরুত্বপূর্ণ।
• একটা virtual tape-কে জন্ম থেকে Glacier Deep Archive পর্যন্ত আর আবার ফেরত অনুসরণ করতে: retrieval-এর সময়, read-only retrieved tape, WORM tape আর Tape Retention Lock সহ।
• একটা gateway বসাতে আর চালাতে: VM বা EC2 host (আর hardware appliance-এর বিদায়), activation, Direct Connect দিয়ে private পথ, bandwidth schedule, monitoring, high availability আর খরচ।
• পরীক্ষার scenario-তে সঠিক উত্তর বেছে নিতে: S3 File Gateway নাকি FSx for Windows File Server, cached নাকি stored volume, Tape Gateway, DataSync।

#Storage-এর জন্য hybrid cloud

#Storage-এর একটা অংশ অফিসেই থেকে যায় কেন

AWS জোর দেয় hybrid cloud-এ: তোমার infrastructure-এর একটা অংশ চলে AWS-এ, একটা অংশ থাকে নিজের ভবনে। এটা migration-এ ব্যর্থতা না। খুব সাধারণ কিছু কারণেই এমন হয়:

• লম্বা migration। ৩০০টা application-ওয়ালা একটা bank এক বছরে সব সরাতে পারে না। বছরের পর বছর কিছু server data centre-এই থাকে, আর তাদেরও storage লাগে।
• নিরাপত্তার শর্ত। কিছু system ভবনের ভেতরেই রাখতে হয়, যেমন core banking server; অথচ তাদের backup cloud-এ যেতে পারে।
• Compliance-এর শর্ত। Regulator হয়তো বলে কিছু record অফিসেই রাখতে হবে, অথবা শহরের বাইরে একটা copy থাকতেই হবে।
• IT কৌশল। কোনো কোম্পানি হয়তো ঠিক করেছে কারখানাগুলো local server-এই চলবে, যাতে internet বন্ধ হলেও উৎপাদন না থামে; কিন্তু backup, archive আর analytics-এর জন্য cloud ব্যবহার করবে।

লেসন ১০.১১-তে (S3-এ যাওয়ার bulk পথগুলো) তুমি S3 File Gateway-কে "path 6" হিসেবে দেখেছ, আর পরিবারের বাকিদের এক অনুচ্ছেদ করে চিনেছ। এই লেসন হলো গভীরে নামার জায়গা: cache আসলে কীভাবে আচরণ করে, volume-এর দুই mode, একটা virtual tape-এর জীবন, gateway কীভাবে বসাতে হয়, আর কোথায় কী ভুল হয়।

#Cloud-native storage-এর ম্যাপ: block, file, object

Gateway বাছার আগে প্রতিটা storage service-কে ম্যাপে বসিয়ে নাও। Data রাখার তিনটা ধরন আছে, আর প্রত্যেকটা আলাদা ভাষায় কথা বলে:

এবার সমস্যাটা সহজেই চোখে পড়ে। অফিসের একটা Linux server Direct Connect বা VPN দিয়ে সরাসরি EFS mount করতে পারে, কারণ EFS NFS বোঝে। S3 বোঝে না। S3 হলো একটা নিজস্ব object API: disk আর share-এর জন্য বানানো file server, database বা backup software কোনো পরিবর্তন ছাড়া এতে লিখতে পারে না। তাহলে অফিসে S3-এর data কীভাবে দেখাবে, বা application নতুন করে না লিখে অফিসের data কীভাবে S3-এ রাখবে? উত্তর: AWS Storage Gateway।

#আগে তিনটা শব্দ: NFS, SMB আর iSCSI

প্রথম দুটো owner-এর note অফিসের দৃশ্য দিয়ে বুঝিয়েছে (লেসন ১০.১১-এ পুরোটা আছে):

• NFS (Network File System) হলো Linux আর Unix-এ file ভাগাভাগির নিয়ম। অফিসে ৫টা Linux computer: ১ নম্বর computer-এর একটা folder বাকি ৪টা এমনভাবে ব্যবহার করে, যেন সেটা তাদের নিজেদের disk-এই আছে।
• SMB (Server Message Block) হলো Windows-এর নিয়ম। একটা folder-এ right-click করে Properties → Sharing → Share: এটাই SMB। একটা কেন্দ্রীয় Windows server এভাবেই সবার PC-তে folder আর printer ভাগ করে দেয়।
• Microsoft Active Directory (AD) হলো Windows network-এর user-দের কেন্দ্রীয় তালিকা। ৫০০ জন কর্মীর কোম্পানিতে কেউ প্রতিটা PC-তে আলাদা password বসায় না। AD-তে ৫০০ জনেরই username আর password থাকে; কেউ যেকোনো PC-তে login করলে PC গিয়ে AD-কে জিজ্ঞেস করে "এই লোক কি আসল?", আর কে কোন folder খুলবে বা কে print করবে, সেটাও AD-ই ঠিক করে।

তৃতীয় শব্দটা note কোথাও বোঝায়নি, অথচ Volume আর Tape Gateway পুরোটাই এর ওপর দাঁড়িয়ে:

• SCSI হলো disk আর tape drive-এর সাথে computer-এর কথা বলার পুরোনো, standard ভাষা: "১,০০০ থেকে ১,০০৭ নম্বর block পড়ো", "এই block-গুলো লেখো", "৪ নম্বর slot-এর tape ঢোকাও"।
• iSCSI ঠিক এই SCSI command-গুলোই IP network দিয়ে পাঠায়। Server-এ চলে একটা initiator; storage দেয় একটা target। Connect হয়ে গেলে server নতুন একটা local disk (বা tape drive) দেখে, আর সেটা যে network-এর ওপারে, তা সে জানেও না, ভাবেও না। চাইলে CHAP authentication দিয়ে initiator-কে প্রমাণ করতে হয় যে সে একটা গোপন কথা জানে।

#Storage Gateway আসলে কী

#Local cache-ওয়ালা একটা সেতু

AWS Storage Gateway একটা hybrid storage service: অফিসের data আর cloud-এর data-র মধ্যে একটা সেতু। তুমি নিজের ভবনে একটা ছোট gateway appliance (একটা VM) চালাও। তোমার server-গুলো তার সাথে চেনা protocol-এই কথা বলে (NFS, SMB বা iSCSI), আর সে AWS-এর সাথে কথা বলে HTTPS-এ। Data শেষমেশ জমা হয় AWS-এর storage-এ (S3, S3 Glacier, EBS snapshot), আর appliance-এর local cache সম্প্রতি ব্যবহৃত data কাছে রাখে, যাতে latency কম থাকে।

Slide-এ চারটা ব্যবহারের কথা আছে, আর প্রতিটা gateway type এগুলোর কোনো কোনোটা সামলায়:

• Disaster recovery: ভবন হারালে AWS-এ থাকা volume snapshot থেকে EC2-তে restore করা যায়।
• Backup আর restore: Tape Gateway আর volume snapshot অন্য শহরে পাঠানো tape-এর জায়গা নেয়।
• Tiered storage: গরম data local cache-এ, সব data S3-এ, ঠান্ডা data lifecycle rule দিয়ে Glacier-এ।
• অফিসে cache আর কম latency-তে file পাওয়া: মূল copy AWS-এ থাকলেও user-রা সাম্প্রতিক file local গতিতে খোলে।

#এক নজরে পুরো পরিবার

Note বলে type তিনটা। আজ আছে চারটা, যার একটা নতুন customer-দের জন্য বন্ধ:

এই ছকের দুটো তথ্যে অনেকে আটকে যায়:

• শুধু S3 File Gateway সাধারণ object হিসেবে তোমার নিজের bucket-এ লেখে। Volume আর tape-এর data service নিজে S3-এ রাখে; S3 console-এ তুমি সেটা খুলতে পারবে না।
• Volume Gateway দুই mode-এই EBS snapshot হিসেবে backup নেয়, cached আর stored দুটোতেই। Note snapshot-এর কথা বলেছে শুধু stored volume-এর বেলায়।

#Amazon S3 File Gateway: গভীরে

#Note-এর সেই পরীক্ষার প্রশ্ন

Note একটা চেনা প্রশ্ন ধরে ধরে সমাধান করেছে: একটা কোম্পানির S3-এ বিশাল একটা dataset আছে, আর অফিসের server-গুলোকে তাদের চেনা file protocol দিয়েই সেটা ব্যবহার করতে হবে। উত্তর S3 File Gateway, আর যুক্তিটা ধাপে ধাপে জানা দরকার:

1. S3 হলো object storage, কাজ করে HTTP আর HTTPS-এ (একটা REST API)। অফিসের server-গুলো ওই API-র ভাষা বোঝে না; তারা বোঝে local file sharing-এর ভাষা, NFS বা SMB।
2. তুমি অফিসে File Gateway (একটা VM) install করো।
3. সে local server-গুলোর সাথে NFS বা SMB-তে কথা বলে।
4. Server-গুলো ভাবে তারা একটা local disk বা NAS-এই পড়ছে আর লিখছে।
5. আড়ালে File Gateway প্রতিটা file-কে অনুবাদ করে একটা S3 object বানায়, আর internet (বা Direct Connect) দিয়ে bucket-এ রাখে, বা সেখান থেকে নামিয়ে আনে।
6. File কে দেখবে বা বদলাবে তা নিয়ন্ত্রণ করতে সে সরাসরি অফিসের Microsoft AD-তে যুক্ত হতে পারে (SMB share-এর জন্য)।

Note-এ এর সবচেয়ে বড় সুবিধাটা এক কথায় বলা আছে: data আসলে থাকে S3-এ (সীমাহীন আর সস্তা), কিন্তু local server-গুলো ভাবে data তাদের কাছেই আছে।

#Cache: write-back আর read-through

File Gateway-কে local মনে হয় cache-এর জন্যই, আর তার বেশিরভাগ ঝামেলাও আসে এখান থেকেই। লেসন ১০.১১ একটা hit আর একটা miss দেখিয়েছিল; এবার পুরো আচরণটা দেখো।

• Write হয় write-back। একটা write cache disk-এ জমা হয়, আর সাথে সাথে "হয়ে গেছে" জানানো হয়। Data এখন dirty: শুধু অফিসেই আছে। Gateway পেছনে asynchronous ভাবে S3-এ upload করে, আর পরে file edit হলে শুধু বদলানো অংশটুকুই যায়।
• Read হয় read-through। Data cache-এ থাকলে উত্তর আসে cache থেকে (hit)। না থাকলে (miss) gateway S3 থেকে শুধু চাওয়া অংশটুকু আনে, উত্তর দেয়, আর cache-এ রেখে দেয়।
• Eviction হয় least recently used নিয়মে, আর শুধু clean data। Cache ভরে গেলে gateway সবচেয়ে কম সম্প্রতি ব্যবহৃত এমন data সরায়, যেটা আগেই S3-এ চলে গেছে। Dirty data সে কখনো সরায় না, সরালে সেটা হারিয়ে যেত।
• মাপ ঠিক করো দুটোর জন্যই। Cache-কে ধরতে হবে গরম working set (মানুষ প্রতি সপ্তাহে যা পড়ে) আর সব dirty data, যেটা ধীর link-এ একটা ব্যস্ত দিনে বা outage-এ জমে যেতে পারে। প্রতি gateway-এ cache সর্বনিম্ন ১৫০ GiB, সর্বোচ্চ ৬৪ TiB; নতুন disk যোগ করো, ব্যবহার হচ্ছে এমন disk-এর মাপ কখনো বদলিও না।
• তিনটা CloudWatch metric-এ চোখ রাখো। CachePercentDirty (কতটা এখনও upload হয়নি), CacheHitPercent (কতগুলো read cache থেকেই মিটছে) আর CachePercentUsed। Dirty-র ভাগ যদি উঁচুতেই থেকে যায়, বুঝবে link তাল মেলাতে পারছে না।

Cache যদি dirty data-তে ভরে যায়, সরানোর মতো কিছুই থাকে না, তাই upload তাল না ধরা পর্যন্ত gateway নতুন write-এর গতি কমিয়ে দেয়। User দেখে save আটকে আছে। অফিসের link বন্ধ হলেই share থেমে যায় না; থামে তখন, যখন cache upload-না-হওয়া data-তে ভরে যায়।

#File, object আর metadata

File থেকে object-এ রূপান্তরটা সহজ, কিন্তু খুঁটিনাটি খরচের জন্য জরুরি:

• একটা file মানে একটা object। File-এর path হয়ে যায় object key (designs/2026/kurta-17.dxf)। Folder হয় folder object, S3 console-এ যেমন দেখো।
• File-এর metadata যায় object-এর metadata-তে: মালিক, group, permission (NFS-এর জন্য POSIX, SMB-এর জন্য Windows ACL) আর সময়ের ছাপ; তাই cache refresh-এর পরে বা অন্য gateway-তেও share-টা একই রকম দেখায়।
• আংশিক বদল দক্ষতার সাথে upload হয়, কিন্তু rename বা metadata বদল পুরো object আবার লেখে: S3-এ rename বলে কিছু নেই, তাই gateway copy করে তারপর মোছে। ১,০০,০০০ file-ওয়ালা একটা folder-এর নাম বদলানো মানে ১,০০,০০০টা copy।
• Bucket-এ versioning চালু থাকলে প্রতিটা save আর প্রতিটা metadata বদল একটা নতুন version বানায়। Noncurrent version মুছে দেওয়ার একটা lifecycle rule দাও, নাহলে বিল চুপচাপ বাড়তেই থাকবে।
• সবচেয়ে বড় file ৫ TiB, অর্থাৎ সবচেয়ে বড় S3 object।

#Share-এর পেছনে storage class আর Glacier

একটা file share নতুন object লেখে S3 Standard (default), Standard-IA, One Zone-IA বা Intelligent-Tiering-এ। সরাসরি Glacier class-এ লিখতে পারে না, আর Glacier Instant Retrieval একেবারেই সমর্থন করে না। তিনটা ফাঁদ:

• IA class আর edit। Standard-IA আর One Zone-IA-র ৩০ দিনের ন্যূনতম সময় আছে। Metadata বদলালে যেহেতু object নতুন করে তৈরি হয়, ব্যস্ত share থেকে সরাসরি IA-তে লিখলে early-deletion charge আসতে পারে। AWS-এর পরামর্শ: Standard-এ লেখো, পরে একটা lifecycle rule object সরিয়ে দিক।
• Lifecycle দিয়ে Glacier। একটা lifecycle rule (লেসন ১০.৫) object-কে Glacier Flexible Retrieval বা Deep Archive-এ সরাতে পারে। ওই file-গুলো share-এ তখনও দেখা যায়, কিন্তু পড়তে বা বদলাতে গেলে I/O error আসে, যতক্ষণ না S3-এ object-টা restore হয়। দরকারে একটা EventBridge rule দিয়ে error ধরে নিজে থেকেই restore চালাও।
• Intelligent-Tiering-এর archive tier। Gateway-এর bucket-এ ঐচ্ছিক Archive Access বা Deep Archive Access tier চালু কোরো না: সেখানে থাকা file share-কে timeout করিয়ে দেয়।

#কে কী খুলবে: file share-এর নিরাপত্তা

• AWS-এর দিক। প্রতিটা file share-এর একটা IAM role থাকে, যেটা gateway-কে তার bucket (বা একটা prefix) পড়তে আর লিখতে দেয়। Data পথে TLS দিয়ে আর জমা অবস্থায় default SSE-S3 দিয়ে encrypted, বা তোমার নিজের key দিয়ে SSE-KMS (লেসন ১০.৮)।
• NFS share ভরসা করে client IP range-এর ওপর: শুধু তালিকার network mount করতে পারে, আর যেকোনো NFS server-এর মতোই root squash-এর বিকল্প আছে। NFS AD ব্যবহার করে না।
• SMB share ব্যবহার করতে পারে Active Directory (gateway তোমার domain-এ যুক্ত হয়; user-রা domain account দিয়ে login করে আর Windows ACL খাটে), অথবা সহজ ক্ষেত্রে একটা password দিয়ে guest access। SMB v3 অফিসের network-এর ভেতরেও traffic encrypt করতে পারে।
• AD একটা নির্ভরতা। Gateway কোনো domain controller-এ পৌঁছাতে না পারলে data ঠিক থাকলেও নতুন SMB session ব্যর্থ হয়। তাকে অন্তত দুটো domain controller দাও।
• কে কোন file খুলল, বদলাল বা মুছল, তার audit log CloudWatch Logs-এ পাঠানো যায়।

#যখন অন্য কেউ bucket-এ লেখে

প্রতিটা folder-এর একটা নিজস্ব cache করা ছবি gateway রেখে দেয়। কোনো application যদি সরাসরি S3-এ object লেখে, বদলায় বা মোছে, gateway cache refresh না করা পর্যন্ত share-এ সেই বদল দেখা যায় না:

• RefreshCache চালাও (দরকারমতো, বা একটা schedule থেকে), অথবা
• একটা সময়সীমা দিয়ে automated cache refresh চালু করো (যেমন ৫ মিনিট): এরপর কোনো folder-এ ঢুকলে gateway S3 থেকে সেটা আবার পড়ে নেয়।

উল্টো দিকের জন্যও একটা সুবিধা আছে: file upload notification। Share দিয়ে লেখা একটা file পুরোপুরি S3-এ upload হলে একটা EventBridge event যায়, তাই cloud-এর workflow (Lambda, Step Functions) object পুরোটা পৌঁছানোর পরেই কাজ শুরু করতে পারে।

আর একটা কঠিন নিয়ম: gateway-গুলোর মধ্যে কোনো locking নেই, gateway আর সরাসরি S3-এ লেখা app-এর মধ্যেও না। দুই অফিস দুটো gateway দিয়ে একই bucket পড়তে পারে, কিন্তু দুজনেই একই file edit করলে শেষ upload-টাই চুপচাপ জিতে যায়। লেখার জন্য প্রতিটা অফিসকে আলাদা prefix দাও।

#S3 File Gateway নাকি FSx for Windows File Server?

সিদ্ধান্তের প্রশ্নটা note-এই আছে:

#FSx File Gateway, সংক্ষেপে

Amazon FSx File Gateway শাখা অফিসে একটা FSx for Windows File Server share-এর সামনে local SMB cache বসাত, যাতে Region থেকে দূরের user-রাও local গতি পায়। AWS এটা ২৮ অক্টোবর ২০২৪ থেকে নতুন customer-দের দেওয়া বন্ধ করেছে; পুরোনো customer-রা চালিয়ে যেতে পারে। নতুন design-এ user-রা Direct Connect বা VPN দিয়ে সরাসরি FSx for Windows-এ connect করে, অথবা data S3-এর হলে S3 File Gateway নেয়। পরীক্ষায় নামটা তবুও আসতে পারে; চিনে রাখো।

#Volume Gateway

#iSCSI দিয়ে block storage

Volume Gateway তোমার server-গুলোকে iSCSI দিয়ে block storage volume দেয়। একটা Windows server নতুন একটা disk দেখে আর সেটা NTFS দিয়ে format করে; Linux server করে ext4 দিয়ে। Database চাইলে তার data file এতে রাখতে পারে। Gateway volume-এর data রাখে S3-এ (service-এর নিজের সামলানো storage-এ, তোমার bucket-এ না) আর backup নেয় EBS snapshot হিসেবে, যেগুলো দিয়ে অফিসের volume restore করা যায়, বা EC2-এর জন্য EBS volume বানানো যায়।

এর দুটো mode, আর পার্থক্যটা হলো মূল copy কোথায় থাকে।

#Cached volume: মূল data AWS-এ

• পুরো volume থাকে S3-এ। Gateway-এর local disk-এ থাকে সম্প্রতি ব্যবহৃত block-এর একটা cache, আর AWS-এর পথে থাকা write-এর জন্য একটা upload buffer।
• Write যায় cache আর upload buffer-এ, "হয়ে গেছে" জানানো হয়, তারপর upload হয়। গরম block-এর read local; ঠান্ডা block-এর read আসে S3 থেকে (ধীরে)।
• প্রতি volume সর্বোচ্চ ৩২ TiB, প্রতি gateway-এ ৩২টা volume, মোট ১,০২৪ TiB।
• কেন বাছবে: একটা site-এ local storage কম, অথচ বড় volume লাগবে, আর বেশিরভাগ data কদাচিৎ পড়া হয়। Disk কিনতে হয় শুধু cache-এর জন্য, পুরো volume-এর জন্য না।

#Stored volume: মূল data অফিসে

• পুরো volume থাকে gateway-এর local disk-এ, তাই প্রতিটা read আর write local: সবচেয়ে কম latency।
• বদলানো block একটা upload buffer পেরিয়ে asynchronous ভাবে AWS-এ যায়, point-in-time snapshot হয়ে (EBS snapshot, incremental), schedule ধরে বা দরকারমতো।
• প্রতি volume সর্বোচ্চ ১৬ TiB, প্রতি gateway-এ ৩২টা volume, মোট ৫১২ TiB।
• কেন বাছবে: application-এর সবকিছুতেই local গতি চাই, আর কোম্পানি টেকসই off-site backup চায়। বিনিময়টা হলো: AWS-এর কাছে থাকে শুধু snapshot, তাই শেষ snapshot-এর পরে লেখা data থাকে শুধু ভবনের ভেতরেই।

#Snapshot আর restore

দুই mode-ই একটা volume-এর EBS snapshot নেয়, schedule ধরে (যেমন প্রতি রাতে) বা দরকারমতো, আর AWS Backup এগুলো সামলাতে পারে। একটা snapshot দিয়ে তুমি:

• অফিসের volume restore করতে পারো: snapshot থেকে একই বা নতুন gateway-তে নতুন একটা gateway volume বানিয়ে;
• cloud-এ চলে যেতে পারো: snapshot থেকে একটা EBS volume বানিয়ে একটা EC2 instance-এ attach করে। Volume Gateway এভাবেই disaster recovery হয়ে ওঠে: অফিস হারালে database গত রাতের snapshot থেকে EC2-তে চলে। (১৬ TiB-এর বড় cached volume-এর snapshot শুধু gateway volume-এ restore করা যায়, EBS-এ না।)
• পরীক্ষার জন্য একটা চালু cached volume থেকে আরেকটা clone বানাতে পারো।

তোমার recovery point হলো snapshot-এর schedule: রাতে একবার snapshot হলে ভবন আর gateway একসাথে হারালে প্রায় একদিনের write হারাতে পারে (RPO আর RTO আছে অধ্যায় ২৩-এ)।

#Upload buffer ভরে গেলে

Upload buffer (প্রতি gateway-এ ১৫০ GiB থেকে ২ TiB) হলো AWS-এর পথে থাকা data-র অপেক্ষার জায়গা। ভারী write আর ধীর link-এর কারণে একটা stored volume-এর buffer ভরে গেলে volume চলে যায় pass-through-এ: server কাজ চালিয়ে যায়, কিন্তু কী কী upload বাকি, gateway তার হিসাব রাখা বন্ধ করে। জায়গা ফিরলে gateway-কে bootstrap করতে হয়, মানে কী বদলেছে খুঁজতে পুরো volume আবার পড়তে হয়, আর সেটা শেষ না হওয়া পর্যন্ত snapshot হালনাগাদ থাকে না। সবচেয়ে ব্যস্ত দিনের মাপে buffer রাখো, আর UploadBufferPercentUsed-এ alarm বসাও। Cached volume-এ buffer ভরে গেলে বরং write ধীর হয়ে যায়।

#Tape Gateway

#কোম্পানিগুলো এখনও tape ব্যবহার করে কেন

Note tape-কে একদম গোড়া থেকে বুঝিয়েছে। আগের দিনের অডিও ক্যাসেট আর ভিসিআর-এর ফিতার কথা মনে আছে, যেখানে ফিতার ভেতরের magnetic অংশে গান বা ছবি রেকর্ড হতো? বড় কোম্পানি আর bank তাদের বিশাল data, যেমন দশ বছরের লেনদেনের record, ঠিক এই জিনিসেরই খুব আধুনিক আর বিশাল সংস্করণে backup রাখে: LTO tape cartridge। কেন tape?

• খুবই সস্তা: hard disk বা SSD-র তুলনায় প্রতি terabyte-এ tape-এর দাম অনেক কম।
• লম্বা সময়ের backup: hard disk নষ্ট হয়ে যেতে পারে, কিন্তু একটা magnetic tape-এ লেখা data অনায়াসে ১০ থেকে ৩০ বছর ভালো থাকে।
• নিরাপত্তা (air-gapped): লেখা হয়ে গেলে tape-গুলো offline করে কোনো সুরক্ষিত vault-এ বা অন্য শহরে পাঠিয়ে দেওয়া হয়, যেমন Iron Mountain-এর মতো কোম্পানির কাছে। তাকে রাখা একটা tape-এর কাছে hacker বা ransomware পৌঁছাতেই পারে না।

সমস্যা হলো সামলানো। Tape ভরে গেলে মানুষকে এসে নতুন tape ঢোকাতে হয়; গাড়ি বা truck-এ করে tape এক জায়গা থেকে আরেক জায়গায় যায়; vault আর গুদামে জায়গা আর টাকা দুটোই লাগে; আর পুরোনো একটা backup restore করতে কয়েক দিন লেগে যায়।

#Tape Gateway আসলে কী

Tape Gateway শারীরিক ঝক্কিটা সরিয়ে দেয়, কিন্তু কাজের ধারাটা রেখে দেয়। Note এটা সুন্দর করে বলেছে:

• এটা একটা software, একটা virtual appliance, যেটা তুমি তোমার local server-এ install করো (VMware, Hyper-V বা KVM-এ, অথবা EC2-এ)।
• এটা একটা virtual tape library (VTL): তোমার network-এ সে এমনভাবে বসে থাকে, যেন সে নিজেই একটা আসল tape drive আর robotic tape library।
• সে iSCSI interface ব্যবহার করে। তোমার কোম্পানির হয়তো আগে থেকেই দামি backup software কেনা আছে (Veeam, Veritas NetBackup, Commvault আর অন্য নামী product), যেটা শুধু iSCSI দিয়ে tape machine-এর সাথেই কাজ করতে জানে। Tape Gateway ঠিক সেভাবেই তার সাথে যুক্ত হয়।
• একই software রেখে দাও। Gateway যেহেতু নিজেকে একটা tape library হিসেবে পরিচয় দেয়, backup software বুঝতেই পারে না সে আসল tape-এ লিখছে নাকি cloud-এ। সে আগের মতোই কাজ করে; নতুন কিছু কিনতে বা শিখতে হয় না।
• কার্যত সীমাহীন storage। Tape cartridge-এর বদলে data network দিয়ে AWS-এ যায়। Tape কখনো ফুরিয়ে যায় না।

#Virtual tape library কীভাবে কাজ করে

প্রতিটা Tape Gateway-এর সাথে আসে একটা media changer (robot) আর ১০টা tape drive, iSCSI device হিসেবে। তুমি barcode দিয়ে virtual tape বানাও, প্রতিটা ১০০ GiB থেকে ১৫ TiB। একটা gateway-এর library-তে একসাথে সর্বোচ্চ ১,৫০০টা tape বা ১ PiB থাকে; পেছনের archive-এর কোনো সীমা নেই।

অন্য gateway-এর মতোই এরও local disk আছে: একটা cache (১৫০ GiB থেকে ৬৪ TiB) আর একটা upload buffer (১৫০ GiB থেকে ২ TiB)। Backup software একটা virtual tape-এ লেখে; gateway data দুই জায়গাতেই রাখে, "হয়ে গেছে" জানায়, আর পরে asynchronous ভাবে S3-এর tape-এ upload করে।

#একটা virtual tape-এর জীবন

1. বানাও একটা tape (console, API দিয়ে, অথবা pool-এ tape কমে গেলে নিজে থেকেই)। Library-তে সেটা দেখা যায় Available হিসেবে।
2. লেখো: backup job media changer দিয়ে tape-টা একটা drive-এ ঢুকিয়ে লেখে। Data upload হয় S3-এ, যেখানে library-র tape-গুলো থাকে।
3. Eject (export) মানেই archive। Backup software একটা tape eject করলে gateway সেটা archive-এ (virtual tape shelf) সরিয়ে দেয়, যার পেছনে tape-এর pool অনুযায়ী S3 Glacier Flexible Retrieval বা S3 Glacier Deep Archive। Note বলে backup "সরাসরি S3 Glacier-এ" যায়; আসলে আগে S3-এ জমা হয়, eject করলে archive হয়।
4. Retrieve। Archive-এর tape সরাসরি পড়া যায় না। তাকে একটা gateway-তে retrieve করতে হয়: Glacier Flexible Retrieval থেকে সাধারণত ৩ থেকে ৫ ঘণ্টা, Deep Archive থেকে সাধারণত ১২ ঘণ্টার মধ্যে। Retrieve করা tape হয় read-only।
5. মুছে ফেলো retention-এর মেয়াদ শেষ হলে। পেছনের storage class-এর মতোই archive করা tape-এর একটা ন্যূনতম charge-এর সময় আছে (Glacier Flexible Retrieval-এ ৯০ দিন, Deep Archive-এ ১৮০ দিন)।

#Tape-কে মুছে ফেলা থেকে বাঁচানো

Air-gapped tape ransomware থেকে বাঁচায়, কারণ তার কাছে কেউ পৌঁছাতেই পারে না। Virtual tape একই উদ্দেশ্যে দুটো সুবিধা পায়:

• WORM tape (write once, read many), tape বানানোর সময়ই ঠিক করা হয়: চালু tape-এর data-র ওপর আর লেখা বা মোছা যায় না, শুধু শেষে যোগ করা যায়।
• একটা custom tape pool-এ Tape Retention Lock: archive করা tape একটা নির্দিষ্ট সময় পর্যন্ত মোছা বা সরানো যায় না, সর্বোচ্চ ১০০ বছর; governance mode-এ (বিশেষ অনুমতিওয়ালা user lock তুলতে পারে) বা compliance mode-এ (কেউই পারে না, root user-ও না)।

#Gateway বসানো আর চালানো

#Gateway কোথায় চলে

Gateway একটা software। তুমি এটা চালাতে পারো:

• অফিসে একটা VM হিসেবে, VMware, Microsoft Hyper-V, Linux KVM বা Nutanix-এ। ন্যূনতম লাগে ৪টা vCPU, ১৬ GiB RAM আর ৮০ GiB system disk, সাথে cache-এর জন্য আলাদা disk (volume আর tape gateway-এ upload buffer-এর জন্যও)। Gateway নামানো, activate আর update করতে AWS-এর দিকে link অন্তত ১০০ Mbps হতে হয়।
• AWS-এ একটা EC2 instance হিসেবে, Storage Gateway AMI থেকে (xlarge বা তার বড় x86 instance)। কাজে লাগে disaster recovery-তে (cloud-এর একটা gateway, যেটা একই data mount করে), যেসব EC2 application-কে S3-এর ওপর NFS বা iSCSI লাগে তাদের জন্য, আর পরীক্ষার জন্য। Cache instance store-এ রেখো না: upload শেষ হওয়ার আগে instance বন্ধ হলে ওই data হারায়।
• একটা hardware appliance হিসেবে: gateway আগে থেকে বসানো একটা 1U server, যেসব site-এ virtualisation নেই তাদের জন্য। ১২ মে ২০২৫ থেকে এটা আর বিক্রি হয় না; চালু appliance মে ২০২৮ পর্যন্ত support পাবে। লেসন ১০.১১ আর পুরোনো course-গুলোতে এখনও এর নাম আছে; নতুন design-এ VM বা EC2 নাও।

#Activation আর network-এর পথ

1. VM বসাও আর তার disk যুক্ত করো।
2. Activate করো: console একবার port 80-তে VM-এ পৌঁছে একটা activation key নেয়, সাথে Region আর endpoint type বেছে নেওয়া হয়। Port 80 শুধু activation-এর সময়ই লাগে।
3. এরপর থেকে gateway বাইরের দিকে HTTPS 443-এ Storage Gateway service আর S3-এর সাথে যুক্ত হয়। AWS থেকে ভেতরে কিছু আসার দরকার নেই।

Endpoint type ঠিক করে পথটা কী হবে:

Gateway dual-stack (IPv4 আর IPv6) endpoint-ও ব্যবহার করতে পারে। অফিসের দিকে শুধু client-দের যা লাগে তা-ই খোলো: NFS 2049 (NFS v3-এর জন্য সাথে 111 আর 20048), SMB 445, iSCSI 3260, আর SMB share-এর জন্য AD-এর port।

#Bandwidth, maintenance আর monitoring

• Bandwidth rate limit আর schedule: upload (আর download) বেঁধে দাও, যেমন সকাল ৯টা থেকে সন্ধ্যা ৬টা পর্যন্ত ৫০ Mbps, রাতে বাঁধন খুলে দাও। Write তবুও পুরো গতিতে cache-এ নামে; ধীর হয় শুধু upload, তাই cache-কে একদিনের dirty data ধরতে হবে।
• Maintenance window: AWS gateway software-এর update ছাড়ে, যেটা তোমার বেছে নেওয়া সাপ্তাহিক একটা সময়ে install হয়। Update-এর সময় gateway অল্প সময়ের জন্য restart নেয়, তাই চুপচাপ একটা ঘণ্টা বেছে নাও।
• CloudWatch metric আর alarm: CachePercentDirty, CacheHitPercent, CachePercentUsed, UploadBufferPercentUsed, আর gateway-এর নিজের health। Gateway-এর log আর file share-এর audit log CloudWatch Logs-এ পাঠানো যায়।

#High availability আর বিপদ

একটা gateway মানে একটা VM: তার host বিকল হলে ওই gateway-এর প্রতিটা share, volume বা tape drive উত্তর দেওয়া বন্ধ করে। দুটো প্রতিরক্ষা:

• একে চালাও VMware vSphere High Availability cluster-এ, disk রাখো shared storage-এ। Storage Gateway VMware HA-র সাথে মিলেমিশে চলে: host বা gateway বিকল হলে কয়েক মিনিটের মধ্যে VM আরেকটা host-এ আবার চালু হয়, আর dirty data-ওয়ালা cache disk টিকে থাকে।
• Cache disk-কে যেকোনো production disk-এর মতোই রক্ষা করো। Dirty data আর কোথাও নেই; cache disk হারালে upload-না-হওয়া data-ও হারায়। Gateway VM হারালে একটা নতুন gateway activate করে AWS থেকে data ফেরত আনো (volume-এর জন্য সর্বশেষ snapshot বা recovery point থেকে); snapshot থেকে gateway VM clone করা সমর্থিত না।

#Cache কত বড়, আর link কি তাল মেলাতে পারবে?

প্রতিটা gateway design-কে এই দুটো প্রশ্নের উত্তর দিতেই হয়। তোমার নিজের অফিসের সংখ্যা দিয়ে চেষ্টা করো:

#খরচ

তুমি টাকা দাও:

• Gateway-এর AWS-এ লেখা data-র জন্য: প্রতি GB প্রায় $0.01, প্রতি gateway-এ মাসে সর্বোচ্চ $125; প্রতি account-এ প্রথম ১০০ GB বিনা খরচে।
• AWS-এ storage-এর জন্য: File Gateway-এ সাধারণ S3 দামে S3 object; Volume Gateway-এ volume storage আর EBS snapshot storage; Tape Gateway-এ S3-এর virtual tape, আর archive করা tape Glacier Flexible Retrieval বা Deep Archive-এর দামে (প্রতি TB মাসে প্রায় ১ ডলার)।
• Request আর retrieval: S3 request, archive থেকে tape retrieval, আর archive করা tape আগেভাগে মোছার charge।
• অফিসে data ফেরত পড়লে AWS থেকে data transfer out, সাধারণ internet বা Direct Connect-এর দামে; একই Region-এর EC2-তে চলা gateway-তে data পাঠাতে খরচ নেই।
• Host: VM হলে তোমার নিজের hardware, নাহলে EC2 instance আর তার EBS volume।

#Storage Gateway আর তার বিকল্পগুলো

Note DataSync-এর সাথে তুলনা করেছে, আর পার্থক্যটা এই অধ্যায়ের সবচেয়ে কাজের বাক্য: Storage Gateway হলো একটা চলমান storage extension (তোমার local storage-এরই অংশ হয়ে যায়, আর data-র পথে বসে থাকে), আর DataSync হলো এক জায়গা থেকে আরেক জায়গায় data copy বা স্থায়ীভাবে migrate করার tool, কাজ শেষে সরে যায়। প্রায়ই দুটো একসাথে চলে: বছরের পর বছরের file-এর প্রথম বড় copy-র জন্য DataSync, তারপর যেসব application লিখতেই থাকে তাদের জন্য একটা File Gateway।

আসল scenario-তে নিজেকে যাচাই করো:

#কোথায় কী ভুল হয়

#System design-এ Storage Gateway

• অফিস আর কারখানার জন্য cloud-নির্ভর file share: প্রতিটা site-এ S3 File Gateway, পেছনে একটাই bucket, প্রতিটা site নিজের prefix-এ লেখে, archive-এর জন্য lifecycle rule। Upload হওয়া মাত্র file analytics, ML আর AWS-এর অন্য service-এর হাতে চলে আসে (file upload notification একটা pipeline চালু করে দিতে পারে)।
• হাসপাতাল বা newsroom-এর জন্য tiered storage: গরম data cache-এ, সব data S3-এ, ঠান্ডা data Glacier-এ, আর application একটুও বদলায় না।
• Backup আর disaster recovery: off-site copy-র জন্য stored volume বা Tape Gateway; site হারালে EBS snapshot থেকে EC2-তে restore (backup আর DR service, অধ্যায় ২৩)।
• Tape library-কে বিদায়: দীর্ঘ নিয়ন্ত্রক retention-এর জন্য Deep Archive pool আর Tape Retention Lock সহ Tape Gateway।
• সেতু ধরে migration: বড় অংশের জন্য DataSync বা Snowball, application অফিসে থাকা পর্যন্ত একটা gateway, তারপর তারা সরে গেলে native AWS storage-এ (S3, EFS, FSx) চলে যাওয়া।
• Private আর নিয়ন্ত্রিত: data internet পেরোতে না পারলে Direct Connect-এর ওপর VPC endpoint; নিজের নিয়ন্ত্রণে SSE-KMS key; প্রতিটা share-এর জন্য IAM role।

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

এই command-গুলোতে উদাহরণের ARN আর নাম ব্যবহার করা হয়েছে। আগে থেকে বসানো একটা পরীক্ষামূলক gateway-এ (একটা VM, বা Storage Gateway AMI থেকে একটা EC2 instance) চালিয়ে দেখো।

# ১. port 80 থেকে key নেওয়ার পর gateway-কে S3 File Gateway হিসেবে activate করো
aws storagegateway activate-gateway --activation-key ABCD1-EFGH2-IJKL3-MNOP4-QRST5 \
  --gateway-name gazipur-design --gateway-timezone GMT+6:00 \
  --gateway-region ap-southeast-1 --gateway-type FILE_S3
#   "GatewayARN": "arn:aws:storagegateway:ap-southeast-1:111122223333:gateway/sgw-12A3456B"

# ২. local disk খুঁজে একটাকে cache বানাও
aws storagegateway list-local-disks --gateway-arn arn:aws:storagegateway:ap-southeast-1:111122223333:gateway/sgw-12A3456B
#   "Disks": [{ "DiskId": "pci-0000:03:00.0-scsi-0:0:1:0", "DiskSizeInBytes": 2199023255552,
#               "DiskAllocationType": "AVAILABLE" }]
aws storagegateway add-cache --gateway-arn <gateway-arn> \
  --disk-ids pci-0000:03:00.0-scsi-0:0:1:0

# ৩. Active Directory-তে যুক্ত হও, তারপর সেটা ব্যবহার করা একটা SMB share বানাও:
#    প্রতি ৩০০ সেকেন্ডে automated cache refresh, আর প্রতিটা file upload শেষ হলে notification
aws storagegateway join-domain --gateway-arn <gateway-arn> --domain-name corp.example.com \
  --user-name svc-sgw --password '<password>' --domain-controllers 10.20.0.10 10.20.0.11
aws storagegateway create-smb-file-share --client-token design-share-1 \
  --gateway-arn <gateway-arn> \
  --role arn:aws:iam::111122223333:role/FileGatewayS3Access \
  --location-arn arn:aws:s3:::garments-designs-example \
  --authentication ActiveDirectory --valid-user-list @Design \
  --default-storage-class S3_STANDARD \
  --cache-attributes CacheStaleTimeoutInSeconds=300 \
  --notification-policy '{"Upload":{"SettlingTimeInSeconds":60}}'
#   "FileShareARN": "arn:aws:storagegateway:ap-southeast-1:111122223333:share/share-5F7D8E9A"

# ৪. কোনো app সরাসরি bucket-এ লেখার পর এখনই একটা folder refresh করো
aws storagegateway refresh-cache --file-share-arn <share-arn> --folder-list /2026/ --recursive

# ৫. Volume Gateway: ২০ TiB-এর একটা cached volume আর প্রতি রাতের snapshot schedule
aws storagegateway create-cached-iscsi-volume --gateway-arn <volume-gateway-arn> \
  --volume-size-in-bytes 21990232555520 --target-name newsroom-archive \
  --network-interface-id 10.30.1.15 --client-token vol-1
#   "TargetARN": "...:gateway/sgw-23B4567C/target/iqn.1997-05.com.amazon:newsroom-archive"
aws storagegateway update-snapshot-schedule --volume-arn <volume-arn> \
  --start-at 1 --recurrence-in-hours 24 --description "nightly"

# ৬. Tape Gateway: Deep Archive pool-এ ২ TiB-এর দশটা tape বানাও, তারপর archive-এর তালিকা দেখো
aws storagegateway create-tapes --gateway-arn <tape-gateway-arn> \
  --tape-size-in-bytes 2199023255552 --client-token tapes-1 --num-tapes-to-create 10 \
  --tape-barcode-prefix BNK --pool-id DEEP_ARCHIVE
aws storagegateway describe-tape-archives
#   "TapeArchives": [{ "TapeBarcode": "BNK00042", "TapeStatus": "ARCHIVED",
#                      "PoolId": "DEEP_ARCHIVE", "TapeSizeInBytes": 2199023255552 }]

# ৭. archive-এর একটা tape gateway-তে ফেরত আনো (read-only), দিনে না, ঘণ্টায়
aws storagegateway retrieve-tape-archive --tape-arn <tape-arn> --gateway-arn <tape-gateway-arn>

# ৮. রবি থেকে বৃহস্পতিবার অফিস সময়ে upload ৫০ Mbps-এ বেঁধে দাও
aws storagegateway update-bandwidth-rate-limit-schedule --gateway-arn <gateway-arn> \
  --bandwidth-rate-limit-intervals \
  'StartHourOfDay=9,StartMinuteOfHour=0,EndHourOfDay=17,EndMinuteOfHour=59,DaysOfWeek=[0,1,2,3,4],AverageUploadRateLimitInBitsPerSec=50000000'

# ৯. cache-এ নজর রাখো: কতটা এখনও upload হয়নি?
aws cloudwatch get-metric-statistics --namespace AWS/StorageGateway \
  --metric-name CachePercentDirty --dimensions Name=GatewayId,Value=sgw-12A3456B Name=GatewayName,Value=gazipur-design \
  --start-time 2026-10-26T00:00:00Z --end-time 2026-10-26T12:00:00Z --period 3600 --statistics Maximum

এরপর domain-এর একটা Windows PC থেকে share-টা হলো সোজা \\10.20.1.15\garments-designs-example। একটা Linux server-এ standard initiator দিয়েই iSCSI volume খুঁজে mount করা যায়:

sudo iscsiadm --mode discovery --type sendtargets --portal 10.30.1.15:3260
sudo iscsiadm --mode node --targetname iqn.1997-05.com.amazon:newsroom-archive \
  --portal 10.30.1.15:3260,1 --login
lsblk          # নতুন একটা ২০ TiB disk, যেমন /dev/sdb, format করার জন্য তৈরি

#সারসংক্ষেপ

মূল কথাগুলো

• Hybrid storage থাকে লম্বা migration, নিরাপত্তা, compliance আর IT কৌশলের কারণে। Storage-এর ম্যাপে block = EBS, instance store; file = EFS, FSx; object = S3, Glacier। EFS NFS বোঝে; S3-এর নিজস্ব API, তাই অফিসের server-কে S3 ব্যবহার করতে Storage Gateway লাগে।
• NFS = Linux-এর file sharing, SMB = Windows-এর file sharing, AD = কেন্দ্রীয় user আর permission, iSCSI = IP দিয়ে SCSI-র disk আর tape command।
• চার ধরনের gateway: S3 File Gateway (NFS/SMB → তোমার bucket-এ প্রতি file একটা object), FSx File Gateway (অক্টোবর ২০২৪ থেকে নতুন customer-দের জন্য বন্ধ), Volume Gateway (iSCSI, data S3-এ, দুই mode-এই EBS snapshot), Tape Gateway (iSCSI VTL, tape S3-এ, eject করলে Glacier Flexible Retrieval বা Deep Archive-এ archive)।
• File Gateway-এর cache write-back আর read-through; সে শুধু clean data সরায়, তাই তাকে ধরতে হয় গরম set আর সব dirty data। CachePercentDirty দেখো। অন্যরা bucket-এ লিখলে cache refresh করো; লেখকদের মধ্যে কোনো locking নেই।
• File share লেখে Standard, IA, One Zone-IA বা Intelligent-Tiering-এ, কখনো সরাসরি Glacier-এ না; পরে lifecycle object সরায়, আর archive-এর file পড়ার আগে restore লাগে। Glacier Instant Retrieval সমর্থিত না।
• Cached volume: মূল data S3-এ, গরম block অফিসে, সর্বোচ্চ ৩২ TiB। Stored volume: সব data অফিসে, asynchronous snapshot, সর্বোচ্চ ১৬ TiB। Snapshot অফিসে restore হয়, অথবা EC2-এর জন্য EBS volume হয় (১৬ TiB পর্যন্ত)।
• Tape Gateway: ১০টা drive + media changer, tape ১০০ GiB–১৫ TiB, প্রতি gateway-এ ১,৫০০ tape / ১ PiB, archive সীমাহীন। Retrieval ৩–৫ ঘণ্টা (Flexible) বা ১২ ঘণ্টার মধ্যে (Deep Archive), read-only। WORM tape আর Tape Retention Lock এদের রক্ষা করে। মূল শব্দ: existing backup software, VTL/iSCSI, eliminate physical tapes।
• বসাও VM হিসেবে (VMware, Hyper-V, KVM, Nutanix) বা EC2-এ; hardware appliance মে ২০২৫ থেকে আর বিক্রি হয় না। Port 80-তে activate, তারপর বাইরের দিকে 443; public, VPC endpoint বা FIPS। একটা gateway মানে একটা VM: HA-র পরিকল্পনা করো, cache disk রক্ষা করো।
• খরচ: লেখা data প্রতি GB প্রায় $0.01, প্রতি gateway-এ মাসে সর্বোচ্চ $125, সাথে storage। Gateway = চলমান extension; DataSync = copy বা migrate করে সরে যাওয়া। S3 ছাড়া Windows + AD → FSx for Windows।

নিজেকে যাচাই করো: Storage Gateway৩১টি প্রশ্ন