AWS-এ High Performance Computing

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

• HPC-র জন্য cloud কেন এত মানানসই (কয়েক মিনিটে হাজার হাজার core, node বাড়িয়ে আগে ফল পাওয়া, শুধু ব্যবহারের ঘণ্টার দাম দেওয়া) বুঝিয়ে বলতে, আর চেনা workload-গুলোর নাম বলতে।
• Loosely coupled আর tightly coupled job আলাদা করে চিনতে, আর দুটোরই design করতে: আলাদা আলাদা task-এর জন্য Batch আর Spot, MPI-র জন্য cluster placement group-এ EFA-সহ Hpc instance।
• টেরাবাইট বা পেটাবাইট ডেটা আনার উপায় বাছতে (DataSync, Direct Connect, Snowball Edge), আর Snowmobile ও Snow Family-র কী হলো তা জানতে।
• Enhanced networking (SR-IOV, ENA, পুরোনো Intel 82599 VF) বোঝাতে, EFA বাড়তি কী দেয় (libfabric দিয়ে OS-bypass, SRD, MPI আর NCCL) আর তার সীমা কী (Linux, একটাই AZ, route করা যায় না) তা বলতে।
• HPC-র storage বাছতে: EBS io2 Block Express, instance store, S3, EFS, আর S3-এর সাথে জোড়া FSx for Lustre (scratch না persistent, lazy load, export)।
• AWS Batch (array আর multi-node parallel job) বা AWS ParallelCluster (YAML, Slurm, EFA, Lustre) দিয়ে cluster automate করতে, আর AWS Parallel Computing Service কোথায় বসে তা জানতে।
• সবকিছু জুড়ে একটা reference architecture দাঁড় করাতে, আর কোন keyword দেখলে পরীক্ষায় কোন service বাছতে হয় চিনতে।

#HPC কেন cloud-এ মানায়

High performance computing (HPC) মানে বিশাল সমস্যা, মানে বিরাট dataset বা খুব ভারী অঙ্ক, দ্রুত সমাধান করা: একটা job একসাথে শত শত বা হাজার হাজার CPU core বা GPU-তে ভাগ করে চালিয়ে। Supercomputer এই কাজ করে; বিশ্ববিদ্যালয়ের নিচতলায় বসানো এক rack server-ও করে।

এই hardware নিজে কিনে রাখা কঠিন। বছরের বেশিরভাগ সময় cluster অলস পড়ে থাকে, আর যে এক সপ্তাহ সবার দরকার, তখন ছোট পড়ে যায়; চার-পাঁচ বছরে পুরোনোও হয়ে যায়। Cloud হিসাবটাই বদলে দেয় (slide p818):

• কয়েক মিনিটে বিশাল capacity: একটা job-এর জন্য ১০,০০০ core চালু করো, ছয় মাসের কেনাকাটার পরে নয়।
• আগে ফল: job যদি ভাগ হতে পারে, node বাড়ালে সময় কমে। ১০০টা node ১ ঘণ্টা আর ১০টা node ১০ ঘণ্টার খরচ প্রায়ই কাছাকাছি, কিন্তু উত্তর আসে নয় ঘণ্টা আগে।
• যতটুকু ব্যবহার, ততটুকু দাম: job শেষ হলে node-গুলো চলে যায়, bill-ও।
• প্রতিটা job-এর জন্য ঠিক machine: এক model-এর জন্য CPU, পরেরটার জন্য GPU, কোনোটাই না কিনে।

চেনা workload: genomics, computational chemistry (ওষুধ আর নতুন উপাদানের design), financial risk modelling (Monte Carlo), আবহাওয়া আর জলবায়ুর পূর্বাভাস, machine learning আর deep learning training, autonomous driving-এর simulation, গাড়ি-জাহাজ-বিমানের জন্য computational fluid dynamics (CFD), তেল-গ্যাসের seismic processing, আর film rendering।

এই লেসনটা আসলে জোড়া লাগানোর লেসন। প্রতিটা building block আগেই শেখা হয়ে গেছে: instance family (লেসন ৪.১), Spot (লেসন ৪.৪), placement group, ENA আর EFA (লেসন ৪.৫), EBS আর instance store (লেসন ৫.২ আর ৫.৩), Snowball, FSx আর DataSync (লেসন ১২.১, ১২.২, ১২.৪)। এখানে তুমি এগুলো জুড়বে, আর শিখবে কোন ধরনের HPC job-এর জন্য কোন জোড়া লাগে। Slide-গুলো বিষয়টাকে চার স্তরে ভাগ করেছে, এই লেসনও তাই করবে: data management আর transfer, compute আর networking, storage, automation আর orchestration।

#HPC job দুই রকমের

কোনো service বাছার আগে একটা প্রশ্ন করো: কাজ চলার সময় node-দের কি একে অপরের সাথে কথা বলতে হয়?

Checkpoint হলো চলমান একটা simulation-এর অবস্থার snapshot, যেটা কিছুক্ষণ পরপর টেকসই storage-এ লেখা হয়। Tightly coupled job একটা node হারালে শূন্য থেকে নয়, শেষ checkpoint থেকে আবার শুরু করে; কত ঘনঘন checkpoint নেবে, সেটা লেখার সময় আর হারাতে পারো এমন কাজের মধ্যে একটা দর-কষাকষি।

#ডেটা আনা-নেওয়া

HPC শুরুই হয় ডেটা দিয়ে: sequencer-এর টেরাবাইট output, seismic survey-র পেটাবাইট, বছরের পর বছরের আবহাওয়ার পর্যবেক্ষণ। প্রথম core চালু হওয়ার আগেই এগুলো AWS-এ পৌঁছাতে হবে, আর ফলাফল প্রায়ই ফেরত যায়। Slide-এ (p819) তিনটা উপায়; তিনটাই আগে বিস্তারিত শেখা, তাই এখানে HPC-র চোখে দেখা:

Online না offline, সিদ্ধান্তটা হয় এই হিসাবে: ১ Gbps পুরো ব্যবহার করলে দিনে প্রায় ১০.৮ TB যায়; ১০ Gbps-এ দিনে প্রায় ১০৮ TB। তাই ৫০০ TB-র একটা dataset ১ Gbps লাইনে প্রায় ৪৬ দিন নেয়, কিন্তু ১০ Gbps Direct Connect-এ ৫ দিনেরও কম। আরও উদাহরণ আর সূত্রটা আছে লেসন ২৩.৫-এ।

AWS-এ পৌঁছানোর পর ডেটার স্থায়ী ঘর S3: টেকসই, সস্তা, আর পরের প্রতিটা ধাপ এখান থেকে পড়তে পারে। Cluster-এর দরকারি দ্রুত file system প্রতিটা run-এর জন্য S3-এর সামনে বানানো হয় (নিচের storage অংশে)।

#Compute: ঠিক instance বাছা

#HPC-র জন্য instance family

লেসন ৪.১ থেকে মনে করো: slide (p820) বলে “CPU optimized, GPU optimized”, আর নোট বলে C family বা P/G family। একটু খুলে বললে:

এখনকার HPC-optimised type, নভেম্বর ২০২৬-এ মিলিয়ে দেখা:

Design-এ দুটো কথা খুব জরুরি: Hpc instance বিক্রি হয় শুধু On-Demand আর Savings Plans-এ, Spot হিসেবে নয়, আর পাওয়া যায় মাত্র কয়েকটা Region আর AZ-এ (Hpc8a চালু হয়েছে US East Ohio আর Europe Stockholm-এ)। Hpc7a-তে পুরো ৩০০ Gbps পেতে তার দুটো network card-এই interface লাগাতে হয়।

#খরচ বাঁচাতে Spot, Spot Fleet আর Auto Scaling

Slide p820 বলে খরচ বাঁচাতে Spot Instance আর Spot Fleet, সাথে Auto Scaling (লেসন ৪.৪)। পরামর্শটা ঠিক loosely coupled কাজের জন্য: একটা Spot Fleet বা AWS Batch-এর compute environment অনেক instance type আর AZ থেকে capacity নেয়, তাই একটা instance ফেরত গেলে যায় শুধু একটা task। Tightly coupled MPI job-এর জন্য এটা ফাঁদ: একটা interruption-এই পুরো job থেমে যায়। HPC-তে Auto Scaling মানে সাধারণত scheduler job queue দেখে compute fleet বাড়ায়-কমায় (Batch-এর compute environment, ParallelCluster-এর Slurm queue), queue খালি হলে শূন্যে নামে।

#Networking: placement, enhanced networking আর EFA

নোট সহজ করে বলেছে: HPC-র server-গুলো নিজেদের মধ্যে প্রচুর ডেটা আদান-প্রদান করে, তাই সাধারণ network দিয়ে কাজ হয় না। বাইরে থেকে ভেতরে, তিনটা হাতিয়ার।

#Cluster placement group

লেসন ৪.৫ থেকে মনে করো: cluster placement group instance-গুলোকে একটা Availability Zone-এর কাছাকাছি hardware-এ, একই high-bandwidth network অংশে গুছিয়ে বসায়। এর ভেতরে দুই instance-এর মধ্যে একটা flow ১০ Gbps পর্যন্ত যেতে পারে (বাইরে ৫ Gbps), আর latency EC2-তে যত কম সম্ভব তত কম। Slide p820 এটাকে দেখায় “same rack, same AZ, low latency, 10 Gbps network” হিসেবে।

HPC design-এ এর তিনটা ফল:

• একই ভাগ্য: কাছাকাছি বসা instance একসাথে নষ্টও হতে পারে (একটা rack switch, একটা power লাইন)। MPI job-এ একটা নষ্ট হলেই সব rank থামে, তাই checkpoint রাখো।
• Capacity: group-এর সব instance কাছাকাছি লাগে। সবগুলো একটাই request-এ, একটাই type-এ launch করো, আর deadline-এর কাজে placement group-এ একটা On-Demand Capacity Reservation দিয়ে আগে থেকে reserve রাখো, নইলে insufficient capacity error আসতে পারে।
• শুধু একটা AZ: EFA traffic এমনিতেও AZ-এর বাইরে যেতে পারে না।

বাকি দুই strategy MPI-র জন্য ভুল হাতিয়ার: spread (আলাদা rack, group-এ AZ-প্রতি সর্বোচ্চ ৭টা চালু instance) হাতে গোনা কয়েকটা জরুরি server-এর জন্য, আর partition (আলাদাভাবে নষ্ট হওয়া rack-এর দল) HDFS, HBase বা Cassandra-র মতো বড় distributed system-এর জন্য।

#Enhanced networking: SR-IOV আর ENA

Enhanced networking না থাকলে virtual machine-এর প্রতিটা packet hypervisor-এর software-এর ভেতর দিয়ে যায়। Enhanced networking ব্যবহার করে SR-IOV (single root I/O virtualization): physical network card নিজেকে অনেকগুলো virtual function হিসেবে দেখায়, আর প্রতিটা instance একটা পায় সরাসরি, তাই packet hypervisor পাশ কাটিয়ে যায়। Slide p821-এ ফলটা লেখা: বেশি bandwidth, বেশি PPS (প্রতি সেকেন্ডে packet), কম latency, কোনো বাড়তি খরচ ছাড়া।

EC2 guide এখনো বলে ENA “100 Gbps পর্যন্ত network speed সমর্থন করে”, slide-এর সংখ্যাও এটাই। যেসব instance-এ কয়েকটা network card আছে, সব মিলিয়ে তারা আরও বেশি পায় (দুটো card-এ interface লাগিয়ে Hpc7a পায় ৩০০ Gbps, সবচেয়ে বড় GPU instance তার চেয়ে অনেক বেশি), কিন্তু ভিত্তি সেই ENA interface-ই। পরীক্ষার জন্য: enhanced networking = SR-IOV = ENA, আর Intel VF হলো পুরোনো উত্তর।

#Elastic Fabric Adapter (EFA)

EFA হলো একটা ENA, সাথে HPC আর machine learning-এর জন্য একটা বাড়তি device। একটা EFA interface (“EFA with ENA”) লাগালে instance দুটো জিনিস পায়: IP traffic-এর জন্য (SSH, S3, file system) সাধারণ ENA device, আর একটা EFA device, যেটা application সরাসরি user space থেকে চালাতে পারে।

দ্রুত পথটা কীভাবে কাজ করে (slide p821: Linux OS পাশ কাটিয়ে কম latency-র, নির্ভরযোগ্য transport দেয়):

1. Application একটা MPI library ব্যবহার করে (Open MPI 4.1 বা পরের, Intel MPI), বা GPU-র জন্য NCCL।
2. সেই library বসে libfabric-এর ওপর, যেটা user space-এ চলা একটা open-source networking API।
3. libfabric message সরাসরি EFA device-এর queue-তে বসিয়ে দেয়: কোনো system call নেই, kernel-এর কপি নেই, TCP stack নেই। এটাই OS-bypass।
4. তারের ওপর EFA ব্যবহার করে SRD (Scalable Reliable Datagram): একটা message-এর packet-গুলো অনেক network পথে ছড়িয়ে যায়, আর হারানোগুলো Nitro hardware কয়েক microsecond-এ আবার পাঠায়, তাই latency কম, আর তার চেয়েও জরুরি, সবসময় প্রায় একই।
5. নতুন instance-এ (Nitro v4 আর পরের) EFA RDMA read আর write সমর্থন করে: ডেটা সরাসরি অন্য instance-এর memory-তে, বা একটা GPU-র memory-তে নামে।

যে নিয়মগুলো পরীক্ষার ফাঁদ হয়ে আসে:

• OS-bypass শুধু Linux-এ। Windows-এ EFA interface সাধারণ ENA-র মতো কাজ করে (একমাত্র ব্যতিক্রম live video-র জন্য AWS Cloud Digital Interface SDK)। Slide p821 বলে “only works for Linux”।
• Route হয় না, একটাই AZ। EFA traffic Availability Zone বা VPC পার হতে পারে না; interface-এর ENA অংশটা আগের মতোই route হয়।
• শুধু সমর্থিত instance type: Hpc, C, M, R-এর বড় size, P আর G GPU type, Trainium, আরও কিছু। describe-instance-types আর network-info.efa-supported filter দিয়ে মিলিয়ে নাও।
• কয়েকটা card-ওয়ালা instance-এ network card-প্রতি একটা EFA, বাকিগুলোতে instance-প্রতি একটা। বাড়তি network card-এর জন্য EFA-only interface-ও আছে (কোনো IP address ছাড়াই)।
• বাড়তি দাম নেই। সমর্থিত instance-এ EFA একটা বিনা পয়সার option।
• Security group-কে নিজের থেকে নিজের দিকে সব traffic allow করতে হয়, কারণ MPI rank-রা অনেক port-এ কথা বলে।

#HPC-র storage

Slide p822 storage-কে দুই ভাগে ভাগ করে: instance-এর সাথে লাগানো storage, আর অনেক instance মিলে ব্যবহার করা network storage। প্রতিটাই আগে শেখা; এখানে দেখো HPC job-এর জন্য কোনটার মানে কী:

Slide p822-এ EFS-এর কথা: “IOPS based on total size, or use provisioned IOPS”। এটা পুরোনো bursting আর provisioned throughput mode-এর বর্ণনা; আজ Elastic throughput default, workload অনুযায়ী নিজেই বাড়ে-কমে, আর যতটুকু ব্যবহার ততটুকু দাম।

#একটা HPC run-এ FSx for Lustre

নোট FSx for Lustre-কে HPC-র সবচেয়ে জরুরি storage বলেছে, পরীক্ষাও তাই মনে করে। Lustre (Linux + cluster থেকে নাম) প্রতিটা file অনেকগুলো storage server-এ ভাগ করে রাখে, আর প্রতিটা client সবগুলোর সাথে একসাথে কথা বলে, তাই file system যত বড়, throughput তত বেশি। লেসন ১২.২-এ যা শিখেছ, এবার HPC-র ঘটনাক্রমে:

1. Run-এর জন্য একটা file system বানাও। Scratch (scratch 2) সবচেয়ে সস্তা, replication নেই, baseline-এর প্রায় ছয় গুণ পর্যন্ত burst করে: যে job-এর input S3-এ আছে আর আবার চালানো যায়, তার জন্য ঠিক। Persistent (persistent 2) AZ-এর ভেতরে replicate করে আর নষ্ট server বদলে দেয়: দীর্ঘ কাজ, shared home directory, আর server নষ্ট হলেও যে ডেটা টিকতে হবে, তার জন্য।
2. S3-এর সাথে জোড়ো একটা data repository association দিয়ে: /fsx/input-এর মতো একটা directory একটা S3 prefix-এর সাথে মেলে (file system-প্রতি ৮টা পর্যন্ত; পুরোনো scratch 1 type-এ নয়)। আসে শুধু metadata, তাই লাখ লাখ object কয়েক মিনিটেই file হিসেবে দেখা যায়।
3. Lazy load: কোনো file প্রথমবার পড়লে তার ডেটা S3 থেকে আসে; তারপর যেকোনো node যতবার পড়ুক, আসে Lustre থেকে। প্রথম read-এ run ধীর হওয়া না চাইলে job-এর আগেই file preload করো।
4. Job চালাও: শত শত node /fsx-কে সাধারণ POSIX file system হিসেবে পড়ে-লেখে।
5. Export: automatic export থাকলে, বা শেষে একটা export data repository task চালালে, নতুন আর বদলানো file S3-এ ফেরত যায়।
6. File system মুছে ফেলো। Input আর output দুটোই S3-এ।

#Automation আর orchestration

HPC environment বারবার হাতে বানানো ধীর আর ভুলে ভরা (নোটের কথা), আর হাতে বানানো cluster সাধারণত চালুই থেকে যায়, কারণ কেউ আবার বসাতে চায় না। দুটো AWS tool এটা automate করে (slide p823), আর তৃতীয়টা এসেছে ২০২৪-এ।

#AWS Batch

AWS Batch batch job (container) চালায় EC2 (On-Demand বা Spot) বা Fargate-এর একটা managed compute environment-এ। তুমি job জমা দাও একটা job queue-তে; queue-র জন্য কত vCPU আর কত memory লাগবে Batch নিজে হিসাব করে, মাপমতো instance চালু করে, ব্যর্থ job আবার চালায়, আর queue খালি হলে environment শূন্যে নামিয়ে আনে। পুরো service-টার আলাদা লেসন আছে লেসন ২৫.৫-এ; HPC-র জন্য দুই রকম job জরুরি:

• Array job: একবার জমা দিলে ১০,০০০ পর্যন্ত child job তৈরি হয়, প্রতিটার নিজের index। Loosely coupled কাজ Spot-এ চালানোর স্বাভাবিক উপায়।
• Multi-node parallel job (slide p823): একটাই job, যেটা কয়েকটা EC2 instance জুড়ে চলে, MPI বা distributed training-এর জন্য। Batch আগে একটা main node চালু করে, তারপর child node-গুলো, সব একসাথে (gang scheduling); main node বেরিয়ে গেলে job শেষ। AWS compute environment-এ একটা cluster placement group রাখার পরামর্শ দেয়, আর multi-node job Spot compute environment-এ বা Fargate-এ চলে না।

#AWS ParallelCluster

AWS ParallelCluster হলো AWS-এর একটা open-source cluster management tool। তুমি একটা YAML file-এ cluster-এর বর্ণনা লেখো, আর pcluster command line (বা ParallelCluster UI, নিজে deploy করা একটা web console) CloudFormation দিয়ে সেটা বানিয়ে দেয়:

• Head node, সাথে Slurm scheduler (বেশিরভাগ HPC কেন্দ্র যেটা আগে থেকেই চালায়);
• Compute node-এর queue, প্রতিটার instance type, কমপক্ষে আর সর্বোচ্চ সংখ্যা (কমপক্ষে ০ মানে queue খালি থাকলে compute-এর কোনো খরচ নেই), On-Demand বা Spot, EFA চালু আর একটা placement group;
• Shared storage: EBS, EFS, FSx for Lustre (নতুন বা আগের, S3-এর সাথে জোড়া), FSx for ONTAP বা OpenZFS;
• আগে থেকে থাকা VPC আর subnet-এ networking (pcluster configure wizard তোমার জন্য VPC আর subnet বানিয়েও দিতে পারে);
• নিজের bootstrap script, CloudWatch-এ monitoring dashboard, login node।

তারপর user-রা head node-এ login করে Slurm-এর sbatch দিয়ে job জমা দেয়। ParallelCluster-এর plugin দিয়ে Slurm queue-তে থাকা job-এর জন্য compute node চালু করে, আর অলস বসে থাকলে (default ১০ মিনিট) সেগুলো terminate করে।

#একটা reference architecture: ঘূর্ণিঝড় forecast-এর cluster

এবার চার স্তর জুড়ে দাও। ঢাকার একটা আবহাওয়া কেন্দ্র ঘূর্ণিঝড় দানা বাঁধলেই একটা WRF-ধাঁচের forecast model চালায় (WRF বহুল ব্যবহৃত open-source আবহাওয়া model):

1. ডেটা আসে: পর্যবেক্ষণের ডেটা আর global model-এর boundary condition কয়েক ঘণ্টা পরপর DataSync দিয়ে, Direct Connect link-এ, একটা S3 bucket-এ আসে। বছরের পর বছরের archive আগেই এসেছে Snowball Edge device-এ।
2. Storage: একটা scratch FSx for Lustre file system input আর output-এর S3 prefix-এর সাথে জোড়া।
3. Cluster: ParallelCluster বানায় Slurm-সহ একটা head node আর Hpc7a instance-এর একটা queue, On-Demand, EFA চালু, একটা AZ-এ একটা cluster placement group-এ, কমপক্ষে ০ আর সর্বোচ্চ ৬৪টা node। ঘূর্ণিঝড়ের মৌসুমের জন্য placement group-এ একটা capacity reservation রাখা।
4. Run: forecaster sbatch দিয়ে model জমা দেয়। Slurm node চালু করে, model Lustre দিয়ে input পড়ে (S3 থেকে lazy load হয়ে), প্রতিটা time step-এ rank-রা EFA দিয়ে সীমানার ডেটা আদান-প্রদান করে, আর simulation-এর প্রতি ঘণ্টায় একটা checkpoint লেখা হয়।
5. ফল বেরোয়: forecast file S3-এ export হয়; Athena আর QuickSight (লেসন ১৭.৫) বা একটা web map দুর্যোগ ব্যবস্থাপনার কর্মকর্তাদের ঝড়ের সম্ভাব্য পথ আর জলোচ্ছ্বাস দেখায়।
6. আবার শূন্যে: অলস compute node বন্ধ হয়; দুই মৌসুমের মাঝে পুরো cluster মুছে ফেলা হয়, পরে একই YAML file থেকে আবার বানানো হয়।

#নিজে একটা বানিয়ে দেখো

একটা workload আর পাঁচটা building block বেছে design-টা চালাও। Spot-এ একটা tightly coupled job, spread placement group-এ genome alignment, বা T3-তে EFA চেষ্টা করে দেখো।

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

• ১৬ node-এর চেয়ে ৬৪ node-এ MPI job ধীর: EFA নেই, বা placement group নেই, তাই latency-ই সব খেয়ে ফেলছে। Node-এ fi_info -p efa চালিয়ে দেখো, আর প্রতিটা instance-এর placement group মিলিয়ে নাও।
• EFA লাগানো, কিন্তু job TCP ব্যবহার করছে: MPI library libfabric দিয়ে build করা হয়নি, security group নিজের দিকের traffic আটকাচ্ছে, বা instance-এ Windows চলছে।
• অন্য AZ বা VPC-র একটা rank-এ EFA দিয়ে পৌঁছানো যায় না: EFA traffic route হয় না। পুরো job একটা AZ-এ রাখো।
• Job শুরুতেই insufficient capacity: placement group-এ সব node আঁটছে না। একটা request-এ একটা type launch করো, placement group-এ capacity reserve রাখো, বা অন্য AZ চেষ্টা করো।
• একটা node হারানোর পর পুরো simulation শূন্য থেকে শুরু: checkpoint নেই, বা checkpoint লেখা ছিল সেই scratch file system-এ, যেটা node-এর সাথেই গেছে। Checkpoint persistent storage-এ লেখো, বা S3-এ export করো।
• Batch-এর multi-node job RUNNABLE-এ আটকে: compute environment Spot ব্যবহার করছে (চলে না), যথেষ্ট vCPU নেই, বা account-এর instance quota চাওয়া node-এর চেয়ে কম।
• প্রতিটা run-এর প্রথম কয়েক মিনিট ধীর: S3 থেকে lazy load। Job-এর আগেই input preload করো।
• Cluster মোছার পর ফলাফল উধাও: output scratch Lustre-এ রয়ে গিয়েছিল, কখনো S3-এ export হয়নি।
• একটা loosely coupled job-এর খরচ আকাশছোঁয়া: এটা On-Demand-এ Hpc instance-এ, cluster placement group-এ চলছে। অনেক instance type আর AZ জুড়ে Spot-সহ Batch ব্যবহার করো।
• Forecast শেষ, তবু bill চলছে: compute queue-র কমপক্ষে সংখ্যা শূন্যের বেশি, বা হাতে বানানো cluster কেউ বন্ধ করেনি।
• ২০২৬-এ Snowball দিয়ে transfer-এর পরিকল্পনা: ৩১ ডিসেম্বর ২০২৬-এর আগে তোমার account এখনো device অর্ডার করতে পারে কি না দেখো; DataSync, Direct Connect বা Data Transfer Terminal-এর পরিকল্পনা রাখো।

#System design-এ HPC

• Loosely coupled pipeline: S3 (input) → অনেক instance type আর AZ জুড়ে Spot-এ AWS Batch array job, retry-সহ → S3 (ফলাফল) → Athena বা QuickSight। Sequencer-এর upload S3-এ নামলেই pipeline চালু করতে EventBridge যোগ করো।
• Tightly coupled cluster: S3 data lake → S3-এর সাথে জোড়া FSx for Lustre → Hpc instance, EFA, একটা AZ-এ cluster placement group-সহ ParallelCluster (Slurm), On-Demand বা reserve করা → checkpoint আর ফলাফল S3-এ export।
• Distributed ML training: S3 dataset → FSx for Lustre → cluster placement group-এ EFA আর NCCL-সহ GPU instance (P family), Slurm (ParallelCluster বা PCS) বা Batch multi-node job দিয়ে চালানো।
• Cloud bursting: on-premises Slurm cluster চলতেই থাকে; চাপ বাড়লে বাড়তিটা Direct Connect দিয়ে AWS-এ যায়, আর FSx for Lustre (বা DataSync) ডেটা cloud node-এর কাছে নিয়ে আসে।
• খরচ: আলাদা task-এ Spot, স্থির HPC ব্যবহারে Savings Plans, deadline-এর জন্য capacity reservation, আর সবসময় শূন্যে নামা।

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

এই command-গুলো AWS CLI v2 আর ParallelCluster CLI (pip install aws-parallelcluster) দিয়ে। Hpc7a node আর Lustre file system দামি: চালানোর আগে পড়ে নাও, আর যা বানাবে সব মুছে দিও।

# 1. Which instance types in this Region support EFA, and how fast are they?
aws ec2 describe-instance-types --region us-east-2 \
  --filters Name=network-info.efa-supported,Values=true Name=instance-type,Values='hpc*' \
  --query "InstanceTypes[].[InstanceType,NetworkInfo.NetworkPerformance,NetworkInfo.MaximumNetworkCards]" \
  --output text
# hpc6a.48xlarge   100 Gigabit   1
# hpc7a.96xlarge   300 Gigabit   2
# hpc8a.96xlarge   300 Gigabit   2

# 2. A cluster placement group, and four instances with EFA launched into it in one request
aws ec2 create-placement-group --group-name cyclone-pg --strategy cluster --region us-east-2
aws ec2 run-instances --region us-east-2 --count 4 --instance-type hpc7a.96xlarge \
  --image-id ami-0abcdef1234567890 --key-name forecast-key \
  --placement GroupName=cyclone-pg \
  --network-interfaces "NetworkCardIndex=0,DeviceIndex=0,InterfaceType=efa,SubnetId=subnet-0bbb2222example,Groups=sg-0ccc3333example"

# 3. On a node: is the EFA provider visible to libfabric?
fi_info -p efa -t FI_EP_RDM
# provider: efa
#     fabric: efa
#     domain: rdmap0s6-rdm
#     version: 122.0
#     type: FI_EP_RDM
#     protocol: FI_PROTO_EFA

# 4. A scratch FSx for Lustre file system, linked to S3 for input and output
aws fsx create-file-system --region us-east-2 --file-system-type LUSTRE \
  --storage-capacity 2400 --subnet-ids subnet-0bbb2222example \
  --lustre-configuration DeploymentType=SCRATCH_2
# { "FileSystem": { "FileSystemId": "fs-0123456789abcdef0", "Lifecycle": "CREATING", ... } }

aws fsx create-data-repository-association --region us-east-2 \
  --file-system-id fs-0123456789abcdef0 --file-system-path /input \
  --data-repository-path s3://forecast-example/input/ --batch-import-meta-data-on-create \
  --s3 "AutoImportPolicy={Events=[NEW,CHANGED,DELETED]}"
aws fsx create-data-repository-association --region us-east-2 \
  --file-system-id fs-0123456789abcdef0 --file-system-path /output \
  --data-repository-path s3://forecast-example/output/ \
  --s3 "AutoExportPolicy={Events=[NEW,CHANGED,DELETED]}"

# Mount it on a node, and preload the input so the run does not wait on lazy loading
sudo mount -t lustre -o relatime,flock fs-0123456789abcdef0.fsx.us-east-2.amazonaws.com@tcp:/abcdefgh /fsx
find /fsx/input -type f -print0 | xargs -0 -n 1 sudo lfs hsm_restore

একটা ParallelCluster configuration, cluster.yaml নামে রাখা:

Region: us-east-2
Image:
  Os: alinux2023
HeadNode:
  InstanceType: c7i.2xlarge
  Networking:
    SubnetId: subnet-0aaa1111example
  Ssh:
    KeyName: forecast-key
Scheduling:
  Scheduler: slurm
  SlurmSettings:
    ScaledownIdletime: 10
  SlurmQueues:
    - Name: cyclone
      CapacityType: ONDEMAND
      Networking:
        SubnetIds:
          - subnet-0bbb2222example
        PlacementGroup:
          Enabled: true
      ComputeResources:
        - Name: hpc7a
          InstanceType: hpc7a.96xlarge
          MinCount: 0
          MaxCount: 64
          Efa:
            Enabled: true
SharedStorage:
  - MountDir: /fsx
    Name: forecast-fsx
    StorageType: FsxLustre
    FsxLustreSettings:
      StorageCapacity: 2400
      DeploymentType: SCRATCH_2
      ImportPath: s3://forecast-example/input
      ExportPath: s3://forecast-example/output

# 5. Build the cluster, check it, submit the model
pcluster create-cluster --cluster-name cyclone --cluster-configuration cluster.yaml --region us-east-2
pcluster describe-cluster --cluster-name cyclone --region us-east-2 --query clusterStatus
# "CREATE_COMPLETE"
pcluster ssh --cluster-name cyclone -i ~/.ssh/forecast-key.pem
sbatch --nodes=64 --ntasks-per-node=192 --exclusive run-wrf.sh
# Submitted batch job 41
squeue
#  JOBID PARTITION     NAME  USER ST  TIME  NODES NODELIST(REASON)
#     41   cyclone  run-wrf  ec2-u CF  0:42     64 cyclone-dy-hpc7a-[1-64]
#  (CF = configuring: Slurm is launching the 64 nodes)

# 6. Loosely coupled work in AWS Batch: one array job of 10,000 alignments on a Spot queue
aws batch submit-job --job-name align-rice --job-queue spot-queue \
  --job-definition bwa-align:3 --array-properties size=10000 \
  --retry-strategy attempts=3
# { "jobName": "align-rice", "jobId": "8a1b2c3d-EXAMPLE" }

# 7. An MPI job in AWS Batch: a multi-node parallel job definition with 8 nodes (On-Demand queue)
aws batch submit-job --job-name cfd-hull --job-queue ondemand-mnp-queue \
  --job-definition openfoam-mnp:1 --node-overrides numNodes=8

# Clean up
pcluster delete-cluster --cluster-name cyclone --region us-east-2
aws fsx delete-file-system --file-system-id fs-0123456789abcdef0 --region us-east-2

#সারসংক্ষেপ

মূল কথাগুলো

• HPC-র জন্য cloud মানানসই: কয়েক মিনিটে হাজার হাজার core, node বাড়িয়ে আগে ফল, শুধু ব্যবহারের ঘণ্টার দাম। Workload: genomics, computational chemistry, financial risk, আবহাওয়া, ML আর deep learning, autonomous driving, CFD।
• Loosely coupled (আলাদা task) → Spot-এ AWS Batch array job, placement group লাগে না, S3। Tightly coupled (MPI) → On-Demand-এ Hpc instance, EFA, একটা AZ-এ cluster placement group, FSx for Lustre, ParallelCluster, checkpoint। Hpc instance Spot হিসেবে বিক্রি হয় না; Batch-এর multi-node job Spot-এ চলে না।
• ডেটা আনা: Direct Connect (private, স্থির, ৪০০ Gbps পর্যন্ত), DataSync (online, যাচাইসহ, S3, EFS বা যেকোনো FSx-এ), Snowball Edge (offline, device-প্রতি ২১০ TB; শুধু পুরোনো customer, support শেষ ৩১ ডিসেম্বর ২০২৬)। Snowmobile ২০২৪-এ বন্ধ, কিন্তু পুরোনো প্রশ্নে exabyte-এর জন্য এখনো আসে। ১ Gbps ≈ দিনে ১০.৮ TB।
• Cluster placement group: একটা AZ, কাছাকাছি hardware, সবচেয়ে কম latency, flow-তে ১০ Gbps; একই ভাগ্য আর capacity-র সীমা। Latency খুব কম, শূন্য নয়; একটা rack-এর নিশ্চয়তাও নেই।
• Enhanced networking = SR-IOV: বেশি bandwidth, বেশি PPS, কম latency। Guide অনুযায়ী ENA 100 Gbps পর্যন্ত (কয়েকটা network card থাকলে instance-প্রতি আরও বেশি); Intel 82599 VF 10 Gbps পর্যন্ত, পুরোনো। ENA Express: সাধারণ TCP-র জন্য SRD, flow-তে ২৫ Gbps।
• EFA = ENA + libfabric দিয়ে OS-bypass, MPI আর NCCL-এর জন্য, বয়ে নেয় SRD, নতুন instance-এ RDMA। OS-bypass শুধু Linux-এ (Windows-এ সাধারণ ENA), AZ বা VPC পার হয় না, শুধু সমর্থিত type, বিনা পয়সায়।
• Storage: io2 Block Express volume-প্রতি ২,৫৬,০০০ IOPS; instance store লাখ লাখ IOPS কিন্তু অস্থায়ী; S3 file system নয়, কিন্তু data lake; shared home folder-এর জন্য EFS; FSx for Lustre শত শত GB/s, লাখ লাখ IOPS, millisecond-এর কম latency, scratch বা persistent, data repository association দিয়ে S3-এর সাথে জোড়া, lazy load আর export-সহ।
• Orchestration: AWS Batch (array job; multi-node parallel job কয়েকটা instance জুড়ে চলে), AWS ParallelCluster (open source, YAML, pcluster, Slurm, EFA, placement group, Lustre, শূন্যে নামা), AWS PCS (managed Slurm, ২০২৪; পরীক্ষার উত্তর এখনো ParallelCluster)।

নিজেকে যাচাই করো: AWS-এ High Performance Computing৩১টি প্রশ্ন