Instance Store: দ্রুত কিন্তু অস্থায়ী

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

• instance store জিনিসটা কী, আর EBS-এর চেয়ে এটা কেন এত দ্রুত, সেটা বোঝাতে পারবে: host-এর ভেতরেই local NVMe disk, মাঝে কোনো network নেই, storage optimised type-এ IOPS লাখ লাখ।
• কোন instance type-এ এটা থাকে চিনতে পারবে (m6id বা c6gd-এর d, I আর D family), আর কেন এর size বাঁধা, কেন এটা কখনো detach, সরানো বা বড় করা যায় না, সেটা বলতে পারবে।
• instance store-এর data ঠিক কখন টেকে (যেকোনো reboot) আর কখন হারায় (stop, hibernate, terminate, type বদলানো, host বদলানো, disk নষ্ট), একদম নিখুঁত করে বলতে পারবে।
• এখানে রাখা জিনিস বাঁচানোর উপায় জানবে: S3 বা EBS-এ কপি করে রাখা, ঝুঁকি বুঝে RAID 0 দিয়ে disk জোড়া দেওয়া, আর built-in hardware encryption-এর ওপর ভরসা রাখা।
• cache, buffer, scratch data আর replicated datastore-এর জন্য instance store বেছে নিতে পারবে, আর জরুরি data-র একমাত্র কপি রাখার জায়গা হিসেবে এটাকে বাতিল করতে পারবে।
• পরীক্ষার চেনা প্রশ্নগুলোর উত্তর দিতে পারবে: অস্থায়ী data-র জন্য সবচেয়ে বেশি IOPS, reboot-এর পর data-র কী হয়, stop-এর পরেও টিকে থাকতে হবে এমন দ্রুত database, আর এক instance থেকে আরেক instance-এ storage সরানো।

#host-এর ভেতরে disk রাখার দরকারটা কী

এই course-এ এতক্ষণ যত disk দেখেছ, সবই ছিল EBS volume। EBS volume কিন্তু তোমার instance যে server-এ চলছে, তার ভেতরে থাকে না। সেটা থাকে একই Availability Zone-এর আলাদা storage server-এ, আর প্রতিটা read আর write AWS network পার হয়ে সেখানে পৌঁছায়। EBS এত নমনীয় হওয়ার কারণও এটাই: volume খুলে অন্য instance-এ লাগানো যায়, snapshot নেওয়া যায়, size বাড়ানো যায়, আর instance stop করলেও data থেকে যায়।

তবে network পার হওয়ার একটা দাম আছে। প্রতিটা I/O-কে যাওয়া-আসা করতে হয়, আর প্রতিটা instance কতটা EBS traffic চালাতে পারবে তারও একটা সীমা আছে। বেশিরভাগ কাজে এতে কিছু যায় আসে না। কিন্তু কিছু কাজে খুব যায় আসে: এমন cache যাকে microsecond-এ উত্তর দিতে হয়, এমন big data job যে terabyte-এর পর terabyte অস্থায়ী file নাড়াচাড়া করে, বা এমন NoSQL database যে প্রতি সেকেন্ডে লাখ লাখ ছোট ছোট random read করে।

এদের জন্য EC2 দেয় instance store: এমন disk, যেগুলো তোমার instance যে host computer-এ চলছে, সেটার গায়েই physically লাগানো।

#instance store আসলে কী

instance store একটা instance-কে অস্থায়ী block-level storage দেয়। এতে থাকে এক বা একাধিক instance store volume, যার প্রতিটা host machine-এর একটা আসল disk (বা তার একটা অংশ), আর তোমার operating system এটাকে একটা block device হিসেবে দেখে।

• কোন ধরনের disk: এখনকার instance type-এ এগুলো NVMe SSD। D family আর পুরনো H1 সস্তায় অনেক জায়গা দিতে HDD ব্যবহার করে। খুব পুরনো কয়েকটা type-এ (C3, I2, M3, R3, X1) NVMe ছাড়া সাধারণ SSD।
• কয়টা আর কত বড়: এটা ঠিক করে instance type আর size। একটা m6id.large পায় একটা 118 GB NVMe SSD; একটা i8g.48xlarge পায় বারোটা 3,750 GB NVMe SSD (45 TB)। নিজের পছন্দমতো size নেওয়ার উপায় নেই।
• দাম: বাড়তি কোনো খরচ নেই। disk-এর দাম instance-এর দামের ভেতরেই ধরা।
• কখন আসে: শুধু launch-এর সময়। NVMe instance store-ওয়ালা type-এ launch-এর সময় সব volume নিজে থেকেই লেগে যায়। পুরনো non-NVMe type-এ block device mapping-এ নিজে লিখে দিতে হতো (ephemeral0 থেকে ephemeral23)। যেভাবেই হোক, চলতে থাকা instance-এ নতুন করে instance store volume যোগ করা যায় না।
• আসার সময় অবস্থা: একদম কাঁচা আর খালি। root volume ছাড়া কিছুই তোমার হয়ে format বা mount করা থাকে না।

#কেন এত দ্রুত

EC2-এর instance type specification থেকে এখনকার কয়েকটা storage optimised উদাহরণ:

এই সংখ্যাগুলো মুখস্থ করার দরকার নেই। মোদ্দা কথাটা মনে রাখো: instance store একটা instance-এই লাখ লাখ IOPS দেয়, যেটা EBS পারে না, কারণ মাঝখানে কোনো network নেই আর অনেকগুলো local disk একসাথে কাজ করে।

#কোন instance type-এ এটা থাকে

সব instance type-এ instance store থাকে না। যেগুলোতে থাকে, সেগুলো চেনার উপায় আছে:

• family-র নামে একটা d (লেসন 4.1): m5d, m6id, m7gd, c6gd, r6id… এই d মানে “local NVMe instance store সহ”। d ছাড়া একই type (m6i, c6g) শুধু EBS-নির্ভর।
• storage optimised I family: i3, i3en, i4i, i4g, i7i, i7ie, i8g, i8ge। বড় NVMe SSD আর সবচেয়ে বেশি random IOPS: NoSQL database, local-এ data রাখা in-memory database, search engine, data warehouse।
• storage optimised D family (আর পুরনো H1): অনেকগুলো বড় HDD, যাতে প্রতি terabyte local storage-এর খরচ সবচেয়ে কম পড়ে: Hadoop/HDFS-এর data node, distributed file system, log processing।
• কিছু GPU আর accelerated type-এও থাকে (যেমন g4dn, g5, p4d), যেখানে training data আর checkpoint রাখতে local disk কাজে লাগে।

বাকি বেশিরভাগ type-এ, যেমন t3, m7i বা c7g-তে, কোনো instance store-ই নেই।

#data কখন টেকে আর কখন হারায়

পরীক্ষা এই অংশটা খুব পছন্দ করে। একটা নিয়মেই সব সারি বোঝা যায়: instance যতক্ষণ একই host-এ আছে আর disk ঠিকঠাক চলছে, instance store-এর data ততক্ষণই বাঁচে। reboot-এ instance তার host-এই থাকে। যেকোনো ঘটনা যেটা host ছেড়ে দেয়, সেটাই disk মুছে দেয়।

stop করলে আসলে কী হয়: EC2 disk-এর encryption key নষ্ট করে দিয়ে instance store-এর প্রতিটা block cryptographically মুছে ফেলে, তারপর host-টা আবার pool-এ ফেরত দেয়। পরে instance start করলে সেটা সাধারণত অন্য একটা host-এ গিয়ে ওঠে, একদম নতুন, খালি, format-ছাড়া disk নিয়ে।

#root volume যখন instance store-এ

root volume হলো সেই disk, যেখান থেকে operating system boot হয়। এখন প্রায় সব instance boot হয় EBS-backed AMI থেকে, তাই তাদের root একটা EBS volume। অনেক আগে AMI instance store-backed-ও হতে পারত (AWS এখন এদের বলে Amazon S3-backed AMI): root volume হতো একটা instance store volume, যেটা launch-এর সময় S3-তে রাখা একটা image template থেকে ভরা হতো।

পরীক্ষার জন্য একটা লাইন মনে রাখো: যে instance-এর root instance store-এ, সেটা stop করা যায় না, শুধু reboot বা terminate করা যায়। (hibernate-ও করা যায় না, লেসন 4.5-এ দেখেছ: hibernation-এর জন্য encrypted EBS root লাগে।) Windows কখনোই instance store root সমর্থন করেনি।

#এখানে রাখা জিনিস কীভাবে বাঁচাবে

#snapshot নেই: backup তোমার কাজ

EBS-এর আছে snapshot, Data Lifecycle Manager আর AWS Backup (লেসন 5.1)। instance store-এর এর একটাও নেই। এর জন্য কোনো snapshot API নেই, আর instance থেকে EBS-backed AMI বানালেও instance store-এর data তাতে ঢোকে না।

এখানে যদি দরকারি কিছু থাকে, টেকসই কোথাও কপি করার কাজটা তোমার:

• S3-তে (aws s3 cp, aws s3 sync): ফলাফল, checkpoint আর backup-এর জন্য।
• একই instance-এ লাগানো একটা EBS volume-এ, যদি block storage হিসেবেই রাখতে হয়।
• অন্য একটা node-এ, যখন application নিজেই replicate করে (নিচের database pattern)।

#instance store volume জুড়ে RAID 0

যে instance-এ কয়েকটা instance store disk আছে, সেখানে সেগুলো আলাদা আলাদা device হিসেবে দেখা যায় (nvme1n1, nvme2n1…)। সবগুলোকে একটা বড় আর দ্রুত volume হিসেবে পেতে চাইলে RAID 0 দিয়ে stripe করো (Linux-এ mdadm)। জায়গা আর throughput মোটামুটি যোগ হয়ে যায়।

RAID 0-তে কোনো redundancy নেই: একটা disk নষ্ট হলে শুধু ওই disk-এর ভাগ না, পুরো array-টাই শেষ। instance store-এ এটা সাধারণত মেনে নেওয়া যায়, কারণ data তো এমনিতেই অস্থায়ী। redundancy চাইলে RAID 1 বা RAID 10 নিতে পারো, তাতে ব্যবহারযোগ্য জায়গা অর্ধেক হয়ে যায়, আর তবুও stop-এ টেকে না।

#encryption আগে থেকেই চালু

NVMe instance store-এর data একটা hardware module-এ XTS-AES-256 block cipher দিয়ে at rest encrypted থাকে। key তৈরি করে ওই hardware নিজেই, প্রতিটা disk-এর key আলাদা, আর instance stop বা terminate হলেই key নষ্ট করে দেওয়া হয়। এই encryption বন্ধ করা যায় না, নিজের key-ও দেওয়া যায় না; এতে কোনো KMS key লাগে না, কোনো setting-ও লাগে না। (KMS key দিয়ে EBS encryption আছে লেসন 5.2-এ।)

#performance-এর দুটো টিপস

• SSD instance store-এ controller-এর ঘর গোছানোর কাজের জন্য আলাদা কোনো জায়গা রাখা থাকে না। তাই যেখানে প্রচুর write হয়, AWS প্রায় ১০% জায়গা partition না করে ফাঁকা রাখতে বলে, যাতে disk ভরতে থাকলেও write-এর গতি না কমে।
• যেসব type-এ সমর্থন আছে, সেখানে মাঝে মাঝে fstrim চালাও, যাতে SSD জানতে পারে কোন block-গুলো এখন ফাঁকা।

#system design-এ এটা কীভাবে কাজে লাগে

#যেখানে মানায়

• Cache: object, ছবি, query-র ফল বা compile করা asset-এর local cache। মুছে গেলে application উৎস থেকে আবার ভরে নেয়।
• Buffer আর কাজের মাঝপথের data: যে data একটু পরেই process হবে বা অন্য কোথাও পাঠানো হবে।
• Scratch আর অস্থায়ী data: video rendering-এর frame, big data job-এর মাঝখানের file (Spark-এর shuffle file, Hadoop job-এর অস্থায়ী output), sort-এর সময় উপচে পড়া file, build directory। input আর শেষ ফল থাকে S3-তে; instance store-এ থাকে শুধু মাঝের ধাপগুলো।
• Replicated datastore: Cassandra, MongoDB replica set, Kafka, Elasticsearch, HDFS। এখানে application নিজেই প্রতিটা data-র কয়েকটা কপি আলাদা আলাদা instance-এ রাখে (সম্ভব হলে আলাদা rack বা আলাদা AZ-এ, লেসন 4.5)। একটা node-এর instance store হারালে cluster বাকি কপি থেকে কাজ চালিয়ে যায়, আর নতুন node-এ হারানো কপিটা আবার বানিয়ে নেয়। গতি পাও instance store-এর, টিকে থাকার নিশ্চয়তা আসে cluster থেকে।
• একই রকম server-এর বহর: যেমন load balancer-এর পেছনে কিছু web server, যাদের প্রত্যেকে boot-এর সময় S3 থেকে একই static content নামিয়ে নিজের কাছে রাখে।

#যেটা কখনো করবে না

জরুরি কোনো কিছুর একমাত্র কপি instance store-এ রাখা: একা একটা database server, user-দের upload করা file, আর্থিক লেনদেনের একমাত্র log। আজ হোক কাল হোক, একটা stop, type বদলানো, host নষ্ট হওয়া বা Spot interruption সেটা মুছে দেবে, আর ফেরত আনার মতো কোনো snapshot থাকবে না।

#দ্রুত database-এর জন্য instance store, নাকি EBS?

তাই সিদ্ধান্তটা সোজা:

• একটা মাত্র high-performance database, যার data stop আর start-এর পরেও থাকতেই হবে → EBS Provisioned IOPS (io2 Block Express; পুরনো ডিজাইনে io1), প্রশ্ন performance-এর ওপর যতই জোর দিক।
• এমন distributed database যে node-গুলোর মধ্যে নিজেই replicate করে, আর যার একদম সর্বোচ্চ IOPS দরকার → instance store বৈধ, আর বেশ চালু একটা পছন্দ।
• অস্থায়ী data, যার চরম গতি দরকার (cache, scratch) → instance store। log বা data warehouse-এর মতো সস্তা, বড়, পরপর পড়া data-র জন্য EBS-এর উত্তর st1 (লেসন 5.2)।

EBS, EFS আর instance store, এই তিনটার মধ্যে পুরো সিদ্ধান্তের ছক আছে লেসন 5.4-এ।

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

# 1. কোন instance type-এ instance store আছে, কত বড়, SSD না HDD?
aws ec2 describe-instance-types \
  --filters Name=instance-storage-supported,Values=true \
  --query "InstanceTypes[].[InstanceType,InstanceStorageInfo.TotalSizeInGB,InstanceStorageInfo.Disks[0].Count,InstanceStorageInfo.Disks[0].Type]" \
  --output table

# শুধু NVMe SSD-ওয়ালাগুলো, একটা family-র জন্য
aws ec2 describe-instance-types \
  --filters Name=instance-storage-supported,Values=true Name=instance-storage-info.disk.type,Values=ssd \
            Name=instance-type,Values="i8g.*" \
  --query "InstanceTypes[].[InstanceType,InstanceStorageInfo.TotalSizeInGB,InstanceStorageInfo.EncryptionSupport]" \
  --output table

# 2. ছোট instance store সহ একটা launch করো (m6id.large: 1 x 118 GB NVMe SSD)
aws ec2 run-instances --image-id $AL2023_AMI --instance-type m6id.large --subnet-id $SUBNET_A

# 3. instance-এ ঢুকে disk খোঁজো। instance store-এর model দেখাবে
#    "Amazon EC2 NVMe Instance Storage"; root দেখাবে "Amazon Elastic Block Store"।
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL

# 4. Format আর mount (disk একদম কাঁচা অবস্থায় আসে)
sudo mkfs.xfs -K /dev/nvme1n1          # -K: নতুন disk-এ ধীর discard বাদ দেয়
sudo mkdir -p /scratch
sudo mount /dev/nvme1n1 /scratch
df -h /scratch
# /etc/fstab-এ "nofail" দাও, অথবা boot script থেকে mount করো: stop আর start-এর পর disk আবার ফাঁকা।

# 5. lifecycle নিজের চোখে দেখো
echo "hello" | sudo tee /scratch/test.txt
sudo reboot                            # আবার ঢুকে mount করো: test.txt এখনো আছে
# aws ec2 stop-instances / start-instances  →  /dev/nvme1n1 আবার খালি, format-ছাড়া

# 6. কয়েকটা instance store disk জুড়ে RAID 0 (i4i.8xlarge-এ: 2 x 3,750 GB)
sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/nvme1n1 /dev/nvme2n1
sudo mkfs.xfs -K /dev/md0
sudo mkdir -p /data && sudo mount /dev/md0 /data
cat /proc/mdstat                       # একটা disk নষ্ট = পুরো array শেষ

# 7. দরকারি জিনিসের backup নাও: instance store-এর snapshot হয় না
aws s3 sync /data/results s3://my-results-bucket/run-42/
sudo fstrim -v /data                   # SSD-কে জানাও কোন block ফাঁকা

#সারসংক্ষেপ

মূল কথা

• instance store হলো block storage, যার disk তোমার instance যে host-এ চলছে তার গায়েই physically লাগানো: এখনকার type-এ NVMe SSD, D family আর H1-এ HDD। দাম instance-এর দামের ভেতরেই।
• এটা EC2-এর সবচেয়ে দ্রুত storage: মাঝে network নেই, অনেকগুলো local disk একসাথে কাজ করে, storage optimised type-এ লাখ লাখ IOPS (একটা i8g.48xlarge-এ প্রায় ৭২ লাখ random read IOPS, যেখানে একই instance EBS থেকে পায় 240,000 IOPS)।
• এটা আসে শুধু নির্দিষ্ট type-এর সাথে: নামে d (m6id, c6gd, r6id), আর I ও D family। disk কয়টা আর কত বড়, সেটা type-এ বাঁধা; পাওয়া যায় শুধু launch-এ, আর কখনো detach, সরানো বা বড় করা যায় না।
• data যেকোনো reboot-এ টেকে (তোমার করা, AWS-এর scheduled, power চলে যাওয়ার পরের)। হারায় stop, hibernate, terminate, instance type বদলানো, retirement, নতুন host-এ automatic recovery, OS shutdown আর disk নষ্ট হলে।
• যে instance-এর root instance store-এ (S3-backed AMI, end of life), সেটা stop করা যায় না।
• snapshot নেই: দামি কিছু থাকলে নিজে S3 বা EBS-এ কপি করো। RAID 0 গতির জন্য disk জোড়া দেয়, কিন্তু একটা disk গেলে সব যায়। data hardware দিয়ে at rest encrypted (XTS-AES-256), সবসময় চালু, stop-এ key নষ্ট।
• এটা কাজে লাগাও cache, buffer, scratch আর অস্থায়ী data, আর replicated datastore-এর জন্য (Cassandra, MongoDB, Kafka, HDFS)। জরুরি data-র একমাত্র কপি কখনো এখানে না।
• stop-এর পরেও টিকে থাকতে হবে এমন high-performance database → EBS io2। এক instance থেকে আরেক instance-এ storage সরানো → EBS।

নিজেকে যাচাই করো: instance store৩০টি প্রশ্ন