ব্যবসায়িক ধারাবাহিকতার জন্য আইটি অবকাঠামো ডিজাইন: High Availability, Disaster Recovery ও এন্টারপ্রাইজ আর্কিটেকচার গাইড

প্রতিটি প্রতিষ্ঠানই এক সময় এমন একটি মুহূর্তের মুখোমুখি হয় যখন তিন বছর আগে নেওয়া অবকাঠামো সিদ্ধান্ত — যেটি তখন যুক্তিসঙ্গত মনে হয়েছিল — সেটিই কারণ হয়ে দাঁড়ায় কেন সোমবার রাত ২টায় ব্যবসা অফলাইন। ERP চালানো একটিমাত্র সার্ভার। কোনো স্ট্যান্ডবাই ডেটাবেজ নেই। যে ব্যাকআপ কখনও টেস্ট করা হয়নি। ইন্টারনেটে যাওয়ার একটিমাত্র পথ থাকা নেটওয়ার্ক। আমি ১৮ বছর ধরে এমন অবকাঠামো ডিজাইন করেছি যা এই মুহূর্তগুলো প্রতিরোধ করে — এবং যেসব প্রতিষ্ঠান পর্যাপ্ত প্রস্তুতি ছাড়াই সেগুলোর সম্মুখীন হয়েছে তাদের সিস্টেম পুনরুদ্ধার করেছি। এই গাইডে এন্টারপ্রাইজ আইটি অবকাঠামো ডিজাইনের সম্পূর্ণ কাঠামো তুলে ধরা হয়েছে যা যা-ই ব্যর্থ হোক না কেন আপনার ব্যবসা চালু রাখে।

১. অবকাঠামো ব্যর্থতার আসল খরচ

আর্কিটেকচার নিয়ে আলোচনার আগে বোঝা দরকার আসলে কী ঝুঁকিতে আছে। ডাউনটাইমের খরচ শিল্প অনুযায়ী ভিন্ন, তবে সংখ্যাগুলো ধারাবাহিকভাবে উল্লেখযোগ্য:

• ম্যানুফ্যাকচারিং: প্রোডাকশন লাইন থেমে যায়, ব্যাচ রেকর্ড সম্পন্ন করা যায় না, চালান বিলম্বিত হয় — ERP ডাউনটাইমের প্রতিটি ঘণ্টা সরাসরি হারানো উৎপাদন ও চুক্তিভিত্তিক জরিমানায় রূপান্তরিত হয়
• ব্যাংকিং ও আর্থিক সেবা: লেনদেন প্রক্রিয়া করা যায় না, গ্রাহকের আস্থা ক্ষয় হয় এবং রেগুলেটরি বাধ্যবাধকতা লঙ্ঘিত হতে পারে — বাংলাদেশ ব্যাংকের সিস্টেম উপলব্ধতা নিয়ে নির্দিষ্ট চাহিদা রয়েছে
• ফার্মাসিউটিক্যাল: ভ্যালিডেটেড কম্পিউটার সিস্টেম ছাড়া উৎপাদন এগোতে পারে না; একটি প্রোডাকশন ব্যাচ চলাকালীন ডেটাবেজ আউটেজ পুরো ব্যাচটিকে গুণগত কারণে বাতিল করাতে পারে
• রিটেইল ও ই-কমার্স: সেল ক্যাম্পেইন চলাকালীন প্রতিটি মিনিট অফলাইন মানে পরিমাপযোগ্য হারানো রাজস্ব

সরাসরি খরচের বাইরেও আছে পুনরুদ্ধারের খরচ: জরুরি ভেন্ডর সাপোর্ট, সম্ভাব্য ডেটা ক্ষতি, স্টাফ ওভারটাইম এবং যেকোনো দীর্ঘ আউটেজের পরে যে সুনামের ক্ষতি হয়। অবকাঠামো ডিজাইন কোনো আইটি খরচ নয় — এটি ব্যবসায়িক ঝুঁকি ব্যবস্থাপনা।

২. তিনটি ধারণা যা আপনাকে আলাদা করতে হবে

High Availability, Disaster Recovery এবং Business Continuity সম্পর্কিত কিন্তু স্বতন্ত্র। এগুলো গুলিয়ে ফেললে এমন আর্কিটেকচার তৈরি হয় যা একটি সমস্যা সমাধান করে অন্যগুলো উন্মুক্ত রেখে দেয়।

২.১ High Availability (HA)

একটি সাইটের ভেতরে কম্পোনেন্ট ব্যর্থতার বিরুদ্ধে সুরক্ষা। HA মানে একটি সার্ভার, ডিস্ক, নেটওয়ার্ক কার্ড বা পাওয়ার সাপ্লাই ব্যর্থ হলেও সিস্টেম চালু থাকে। HA অর্জিত হয় রিডানডেন্সির মাধ্যমে — একাধিক কম্পোনেন্ট একই কাজ করে যাতে একটির ব্যর্থতা সেবাটিকে নামিয়ে না ফেলে। সাধারণ HA লক্ষ্য: ৯৯.৯% আপটাইম (বছরে ৮.৭ ঘণ্টা ডাউনটাইম) থেকে ৯৯.৯৯% (বছরে ৫২ মিনিট)।

২.২ Disaster Recovery (DR)

সাইট-পর্যায়ের ব্যর্থতার বিরুদ্ধে সুরক্ষা। DR মানে একটি সম্পূর্ণ ডেটা সেন্টার, ভবন বা ভৌগোলিক অবস্থান অনুপলব্ধ হলে — আগুন, বন্যা, বিদ্যুৎ বিভ্রাট, র‍্যানসমওয়্যার বা ভৌত ক্ষতির কারণে — ব্যবসা পরিচালনা পুনরায় শুরু করতে পারে। DR-এ থাকে একটি সেকেন্ডারি সাইট যেখানে আপনার সিস্টেমের একটি সিঙ্ক্রোনাইজড বা প্রায়-সিঙ্ক্রোনাইজড কপি থাকে। মূল মেট্রিক: Recovery Time Objective (RTO — পুনরুদ্ধারে কত সময় লাগে) এবং Recovery Point Objective (RPO — কতটা ডেটা হারানো সহনীয়)।

২.৩ Business Continuity (BC)

বৃহত্তর পরিকল্পনা যা HA ও DR অন্তর্ভুক্ত করে। BC শুধু প্রযুক্তি নয়, বরং যেকোনো বিঘ্নের মধ্যেও ব্যবসা চালু রাখতে প্রয়োজনীয় মানুষ, প্রক্রিয়া ও যোগাযোগও অন্তর্ভুক্ত করে — এমন পরিস্থিতিও যেখানে আইটি সিস্টেম ঠিক আছে কিন্তু ভবনে ঢোকা যাচ্ছে না, কিংবা মূল কর্মীরা অনুপলব্ধ।

একটি সম্পূর্ণ এন্টারপ্রাইজ অবকাঠামো ডিজাইনকে অবশ্যই তিনটি স্তরই সামলাতে হবে। অধিকাংশ প্রতিষ্ঠান HA মোটামুটি ভালোভাবে করে, DR অপর্যাপ্তভাবে সামলায় এবং BC খুব কমই আনুষ্ঠানিক করে।

৩. HA + DR আর্কিটেকচার কাঠামো

এন্টারপ্রাইজ অবকাঠামো ডিজাইনে আমি যে আর্কিটেকচার কাঠামো ব্যবহার করি তা পাঁচটি স্তর ঘিরে গড়া, প্রতিটিকে রিডানডেন্সি ও পুনরুদ্ধারের জন্য ডিজাইন করতে হবে:

Layer 1: Compute      — Servers, VMs, clusters
Layer 2: Storage      — NAS, SAN, ASM, replication
Layer 3: Network      — Switches, routers, firewalls, load balancers
Layer 4: Database     — Oracle RAC (HA), Data Guard (DR)
Layer 5: Application  — WebLogic clusters, middleware, app servers

প্রতিটি স্তর স্বাধীনভাবে ডিজাইন করতে হবে — কোনো এক স্তরের ব্যর্থতা যেন সম্পূর্ণ আউটেজে গড়িয়ে না যায়। যদি compute রিডানডেন্ট হয় কিন্তু storage-এ একটি single point of failure থাকে, তবে আর্কিটেকচার তার সবচেয়ে দুর্বল স্তরের মতোই স্থিতিস্থাপক।

৪. Layer 1 — Compute আর্কিটেকচার

৪.১ ফিজিক্যাল সার্ভার বনাম ভার্চুয়ালাইজেশন

Oracle প্রোডাকশন ডেটাবেজের জন্য পারফরম্যান্স-ক্রিটিক্যাল ওয়ার্কলোডে আমি সাধারণত ভার্চুয়াল মেশিনের চেয়ে ফিজিক্যাল সার্ভার সুপারিশ করি। Oracle লাইসেন্সিং per-core, আর ভার্চুয়ালাইজেশন লাইসেন্সিং কমপ্লায়েন্স জটিল করে ও ওভারহেড যোগ করে। বিশেষত Oracle RAC-এর ক্ষেত্রে প্রোডাকশনে সুপারিশ bare-metal — VMware সাপোর্টেড কিন্তু ক্লাস্টার ইন্টারকানেক্ট যোগাযোগে ল্যাটেন্সি যোগ করে।

অ্যাপ্লিকেশন সার্ভারের (WebLogic, মিডলওয়্যার, ওয়েব টিয়ার) জন্য ভার্চুয়ালাইজেশন উপযুক্ত এবং VM স্ন্যাপশট ও লাইভ মাইগ্রেশনের মাধ্যমে দ্রুত পুনরুদ্ধারের সুযোগ দেয়।

৪.২ সার্ভার সাইজিং পদ্ধতি

সার্ভার সাইজিং অনুমান নয়। সঠিক পদ্ধতি শুরু হয় ওয়ার্কলোড পরিমাপ দিয়ে:

• বর্তমান পিক CPU ব্যবহার — একক স্ন্যাপশট নয়, ৪ সপ্তাহ ধরে পরিমাপ করা। লক্ষ্য: স্বাভাবিক অবস্থায় পিক ব্যবহার ধারণক্ষমতার ৬০–৭০%-এর বেশি হওয়া উচিত নয়, প্রবৃদ্ধি ও ব্যর্থতার পরিস্থিতির জন্য জায়গা রেখে
• মেমরি চাহিদা — Oracle SGA + PGA + OS + অ্যাপ্লিকেশন। একটি সাধারণ ভুল: ৩ বছরের প্রবৃদ্ধি হিসাব না করে বর্তমান ডেটা ভলিউমের জন্য মেমরি সাইজ করা
• I/O প্রোফাইল — IOPS (রিড বনাম রাইট), ল্যাটেন্সি চাহিদা, সিকোয়েন্সিয়াল বনাম র‍্যান্ডম I/O। এটি স্টোরেজ নির্বাচনকে কাঁচা ধারণক্ষমতার চেয়ে বেশি চালিত করে
• নেটওয়ার্ক থ্রুপুট — বিশেষত RAC ক্লাস্টার ইন্টারকানেক্ট (প্রাইভেট নেটওয়ার্ক), যা low-latency (< ১ms) ও high-bandwidth (ন্যূনতম 10 GbE, ব্যস্ত ক্লাস্টারে 25 GbE সুপারিশকৃত) হতে হবে

৪.৩ Compute স্তরে রিডানডেন্সি

প্রতিটি প্রোডাকশন সার্ভারে থাকা উচিত:

• আলাদা PDU-তে (এবং আদর্শভাবে আলাদা UPS সার্কিটে) সংযুক্ত ডুয়াল পাওয়ার সাপ্লাই
• পাবলিক নেটওয়ার্কের জন্য ডুয়াল নেটওয়ার্ক ইন্টারফেস কার্ড (NIC bonding / teaming)
• ক্লাস্টার ইন্টারকানেক্ট (RAC), স্টোরেজ নেটওয়ার্ক (SAN) ও ম্যানেজমেন্টের (IPMI/iDRAC) জন্য আলাদা NIC
• লোকাল OS ডিস্কের জন্য হার্ডওয়্যার RAID (ন্যূনতম RAID 1)
• রিমোট পাওয়ার কন্ট্রোল ও কনসোল অ্যাক্সেসের জন্য out-of-band ম্যানেজমেন্ট (iDRAC, iLO)

৫. Layer 2 — Storage আর্কিটেকচার

এন্টারপ্রাইজ পরিবেশে স্টোরেজই সবচেয়ে সাধারণ single point of failure। একটি সুপরিকল্পিত স্টোরেজ আর্কিটেকচারকে অবশ্যই ডিস্ক ব্যর্থতা, কন্ট্রোলার ব্যর্থতা এবং DR পরিস্থিতিতে সাইট ব্যর্থতা টিকিয়ে থাকতে হবে।

৫.১ Oracle-এর জন্য স্টোরেজ অপশন

স্টোরেজ টাইপ	যেজন্য সেরা	Oracle ব্যবহার
SAN (FC/iSCSI)	উচ্চ-পারফরম্যান্স ডেটাবেজ, RAC শেয়ারড স্টোরেজ	Oracle RAC-এর শেয়ারড স্টোরেজ প্রয়োজন — SAN বা NFS
NAS (NFS)	ফাইল শেয়ারিং, NFS-এ Oracle ASM (Direct NFS)	Oracle Direct NFS (dNFS) ভালো পারফরম্যান্স দেয়
All-Flash (NVMe)	ল্যাটেন্সি-সংবেদনশীল OLTP ওয়ার্কলোড	উচ্চ-লেনদেনের ERP ডেটাবেজের জন্য আদর্শ
Hybrid Flash	খরচ-সংবেদনশীলতাসহ মিশ্র ওয়ার্কলোড	ফ্ল্যাশ টিয়ারে হট ডেটা, স্পিনিং ডিস্কে কোল্ড ডেটা

৫.২ Oracle ASM — Automatic Storage Management

Oracle ডেটাবেজের জন্য ASM হলো সুপারিশকৃত স্টোরেজ ম্যানেজমেন্ট স্তর। ASM যা দেয়:

• ডিস্কজুড়ে স্বয়ংক্রিয় ডেটা বণ্টন — কোনো ম্যানুয়াল স্ট্রাইপিং নেই
• বিল্ট-ইন মিররিং (Normal Redundancy = ২-way, High Redundancy = ৩-way)
• অনলাইন ডিস্ক গ্রুপ রিব্যালান্সিং — ডাউনটাইম ছাড়াই ডিস্ক যোগ বা অপসারণ
• RAC ক্লাস্টারের জন্য শেয়ারড স্টোরেজ — একাধিক নোড একই ASM ডিস্ক গ্রুপে অ্যাক্সেস করে
• Fast Mirror Resync — একটি ডিস্ক অফলাইন হয়ে ফিরে এলে শুধু পরিবর্তিত এক্সটেন্টগুলো রিসিঙ্ক হয়

-- Create ASM disk group with high redundancy (3-way mirror)
CREATE DISKGROUP DATA HIGH REDUNDANCY
  FAILGROUP fg_ctrl1 DISK '/dev/sdb' NAME DATA_0001,
                          '/dev/sdc' NAME DATA_0002,
  FAILGROUP fg_ctrl2 DISK '/dev/sdd' NAME DATA_0003,
                          '/dev/sde' NAME DATA_0004,
  FAILGROUP fg_ctrl3 DISK '/dev/sdf' NAME DATA_0005,
                          '/dev/sdg' NAME DATA_0006
ATTRIBUTE 'AU_SIZE'='4M', 'COMPATIBLE.ASM'='19.0';

৬. Layer 3 — Network আর্কিটেকচার

এন্টারপ্রাইজ পরিবেশে নেটওয়ার্ক ডিজাইনে প্রায়ই কম বিনিয়োগ হয়। একটি সুপরিকল্পিত compute ও storage স্তর একটি single-switch নেটওয়ার্কের কারণে পুরোপুরি ভেঙে পড়তে পারে।

৬.১ নেটওয়ার্ক সেগমেন্টেশন

প্রোডাকশন এন্টারপ্রাইজ নেটওয়ার্ককে আলাদা VLAN/সেগমেন্টে ভাগ করা উচিত:

• পাবলিক / অ্যাপ্লিকেশন নেটওয়ার্ক: ইউজার ট্রাফিক, অ্যাপ্লিকেশন-থেকে-ডেটাবেজ সংযোগ
• Oracle RAC ক্লাস্টার ইন্টারকানেক্ট: প্রাইভেট, ডেডিকেটেড, 10/25 GbE, শুধুমাত্র low-latency সুইচ
• স্টোরেজ নেটওয়ার্ক: SAN ট্রাফিকের জন্য iSCSI বা ডেডিকেটেড FC ফ্যাব্রিক
• ম্যানেজমেন্ট নেটওয়ার্ক: IPMI, iDRAC, সুইচ ম্যানেজমেন্ট — প্রোডাকশন থেকে বিচ্ছিন্ন
• ব্যাকআপ নেটওয়ার্ক: RMAN ব্যাকআপ ট্রাফিক — ব্যাকআপ জব যাতে প্রোডাকশন নেটওয়ার্ক ভরিয়ে না ফেলে
• DR রেপ্লিকেশন নেটওয়ার্ক: Oracle Data Guard redo transport — লগ শিপিংয়ের জন্য ডেডিকেটেড ব্যান্ডউইথ

৬.২ নেটওয়ার্ক রিডানডেন্সি

প্রতিটি গুরুত্বপূর্ণ নেটওয়ার্ক পথের একটি failover পথ থাকতে হবে:

• ক্রস-কানেক্টসহ ডুয়াল top-of-rack সুইচ — কোনো একক সুইচ ব্যর্থতা সব সার্ভার পোর্ট নামায় না
• সব সার্ভার নেটওয়ার্ক ইন্টারফেসে NIC bonding (LACP / active-passive)
• অ্যাক্সেস ও ডিস্ট্রিবিউশন সুইচের মধ্যে রিডানডেন্ট আপলিংক
• রিডানডেন্ট ইন্টারনেট সংযোগ — আদর্শভাবে দুটি আলাদা রাউটারে দুই প্রোভাইডার
• রিডানডেন্ট ফায়ারওয়াল জোড়া (active-standby বা active-active)

৬.৩ ফায়ারওয়াল ও নিরাপত্তা জোনিং

ডেটাবেজ টিয়ার কখনও ইন্টারনেট বা ইউজার ওয়ার্কস্টেশন থেকে সরাসরি অ্যাক্সেসযোগ্য হওয়া উচিত নয়। একটি সঠিক DMZ আর্কিটেকচারে থাকে:

• DMZ জোনে ওয়েব/অ্যাপ্লিকেশন সার্ভার
• অভ্যন্তরীণ অ্যাপ্লিকেশন জোনে অ্যাপ্লিকেশন সার্ভার
• একটি সীমাবদ্ধ ডেটাবেজ জোনে ডেটাবেজ সার্ভার — শুধু অ্যাপ্লিকেশন সার্ভার নির্দিষ্ট Oracle listener পোর্টে সংযোগ করতে পারে
• MFA-সুরক্ষিত অ্যাক্সেসসহ একটি ডেডিকেটেড ম্যানেজমেন্ট জোনে ম্যানেজমেন্ট সার্ভার

৭. Layer 4 — Database HA ও DR (Oracle RAC + Data Guard)

Oracle-ভিত্তিক এন্টারপ্রাইজ সিস্টেমের জন্য Oracle RAC ও Oracle Data Guard-এর সংমিশ্রণ ডেটাবেজ উপলব্ধতা ও ডিজাস্টার রিকভারির গোল্ড স্ট্যান্ডার্ড দেয়।

৭.১ High Availability-এর জন্য Oracle RAC

Oracle RAC একই ডেটাবেজ একসাথে একাধিক সার্ভার নোডজুড়ে চালায়। সব নোড একই ASM স্টোরেজ শেয়ার করে। কোনো নোড ব্যর্থ হলে বাকি নোডগুলো কোনো আউটেজ ছাড়াই অ্যাপ্লিকেশনকে সেবা দিতে থাকে। TAF (Transparent Application Failover) সক্রিয় সেশনগুলো স্বয়ংক্রিয়ভাবে পুনঃসংযুক্ত করে।

একটি মাঝারি আকারের প্রতিষ্ঠানের জন্য ন্যূনতম প্রোডাকশন RAC কনফিগারেশন:

• ২টি RAC নোড (HA-এর জন্য ন্যূনতম) — বড় ওয়ার্কলোডের জন্য ৪টি নোড
• প্রতিটি নোডে Oracle Grid Infrastructure
• শেয়ারড ASM ডিস্ক গ্রুপ (SAN বা NAS)
• প্রাইভেট ক্লাস্টার ইন্টারকানেক্ট: প্রতি নোডে 2 × 10 GbE (bonded)
• পাবলিক নেটওয়ার্ক: প্রতি নোডে 2 × 1 GbE (bonded)
• SCAN (Single Client Access Name) — ৩টি SCAN IP, DNS round-robin

৭.২ Disaster Recovery-এর জন্য Oracle Data Guard

Data Guard DR সাইটে ডেটাবেজের একটি সিঙ্ক্রোনাইজড কপি রক্ষণাবেক্ষণ করে। প্রাইমারি সাইট ব্যর্থ হলে স্ট্যান্ডবাই ডেটাবেজ সক্রিয় হয় — হয় স্বয়ংক্রিয়ভাবে (Fast-Start Failover ব্যবহার করে) অথবা ম্যানুয়ালি — এবং নতুন প্রাইমারি হয়ে ওঠে।

মূল DR ডিজাইন সিদ্ধান্তগুলো:

• Protection mode: Maximum Performance (async, প্রায়-শূন্য RPO) বনাম Maximum Availability (sync, শূন্য ডেটা ক্ষতি) — RPO চাহিদা ও সাইটগুলোর মধ্যে নেটওয়ার্ক ল্যাটেন্সির ভিত্তিতে বেছে নিন
• RTO লক্ষ্য: DR সাইট কত দ্রুত সক্রিয় হতে হবে? ম্যানুয়াল failover = ১৫–৩০ মিনিট। স্বয়ংক্রিয় failover (FSFO) = ৩০–৬০ সেকেন্ড
• Standby type: Physical standby (সবচেয়ে সাধারণ, সর্বনিম্ন ওভারহেড) বনাম Active Data Guard (রিপোর্টিং অফলোডের জন্য স্ট্যান্ডবাইয়ে read-only অ্যাক্সেস)
• DR সাইট অবকাঠামো: DR সাইটকে কি পূর্ণ প্রোডাকশন ধারণক্ষমতায় চালাতে হবে? নাকি প্রাইমারি পুনরুদ্ধার হওয়া পর্যন্ত কম ধারণক্ষমতায় চালানো গ্রহণযোগ্য?

৭.৩ Maximum Availability Architecture (MAA)

Oracle-এর Maximum Availability Architecture একটি সর্বাত্মক HA/DR/backup সমাধানে RAC + Data Guard + RMAN একত্র করে। একটি দুই-সাইট MAA ডিপ্লয়মেন্টের জন্য:

PRIMARY SITE (Dhaka):
  ├── RAC Node 1 (Oracle 26ai)
  ├── RAC Node 2 (Oracle 26ai)
  ├── ASM Disk Group — SAN storage (High Redundancy)
  └── Observer (for FSFO)

DR SITE (Chittagong / separate facility):
  ├── Physical Standby Node 1
  ├── Physical Standby Node 2 (optional — standby RAC)
  ├── ASM Disk Group — separate SAN storage
  └── Data Guard Broker managing the configuration

BACKUP:
  └── RMAN backups to separate media (tape or cloud) — both sites

৮. Layer 5 — Application Tier HA

অ্যাপ্লিকেশন টিয়ার HA ছাড়া ডেটাবেজ HA খুব কম অর্জন করে — যদি অ্যাপ্লিকেশন সার্ভার একটি single point of failure হয়, তবে ডেটাবেজ যা-ই হোক ব্যবহারকারীরা অফলাইন। Oracle WebLogic HA চিত্রটি সম্পূর্ণ করতে প্রয়োজনীয় অ্যাপ্লিকেশন-টিয়ার ক্লাস্টারিং দেয়।

• WebLogic cluster: একই অ্যাপ্লিকেশন হোস্ট করা একাধিক managed server — অনুরোধ সব উপলব্ধ নোডজুড়ে লোড-ব্যালান্স হয়
• Session replication: HTTP সেশন স্টেট ক্লাস্টার সদস্যদের মধ্যে রেপ্লিকেট হয় — একটি managed server মারা গেলে ব্যবহারকারীরা সেশন না হারিয়ে স্বচ্ছভাবে অন্য নোডে পুনঃনির্দেশিত হন
• Load balancer: হার্ডওয়্যার বা সফটওয়্যার (যেমন F5, HAProxy, Oracle HTTP Server) আগত অনুরোধ বণ্টন করে ও ব্যর্থ সার্ভার শনাক্ত করে
• Admin Server separation: WebLogic Administration Server একটি ডেডিকেটেড, হালকা মেশিনে চলে — কখনও প্রোডাকশন লোড সামলানো managed server-এর একই সার্ভারে নয়

৯. ক্যাপাসিটি প্ল্যানিং — ভবিষ্যতের জন্য সাইজিং

আজকের ওয়ার্কলোডের জন্য সাইজ করা অবকাঠামো সঠিক প্রবৃদ্ধি পরিকল্পনা ছাড়া ১৮–২৪ মাসের মধ্যেই অপর্যাপ্ত হয়ে পড়ে। আমার ক্যাপাসিটি প্ল্যানিং পদ্ধতি ত্রৈমাসিক চেকপয়েন্টসহ একটি ৩ বছরের দিগন্ত ব্যবহার করে:

৯.১ ডেটা ভলিউম প্রবৃদ্ধি

বর্তমান ডেটাবেজ সাইজ ও লেনদেন প্রবৃদ্ধির হার পরিমাপ করুন। সক্রিয় প্রতিষ্ঠানের ERP ডেটাবেজ সাধারণত বছরে ১৫–৩০% বাড়ে। বর্তমান আকারের ন্যূনতম ৩ গুণের জন্য স্টোরেজ পরিকল্পনা করুন।

৯.২ ইউজার ও লেনদেন প্রবৃদ্ধি

ব্যবসায়িক প্রবৃদ্ধি পরিকল্পনাকে আইটি ওয়ার্কলোডে ম্যাপ করুন। উৎপাদন ভলিউমে পরিকল্পিত ৪০% বৃদ্ধি মানে ERP লেনদেন, ব্যাচ প্রসেসিং সময় ও ডেটাবেজ I/O-তে সমানুপাতিক বৃদ্ধি। পারফরম্যান্স অবনতি ছাড়াই বর্তমান লেনদেন ভলিউমের ৩ গুণ পিক লোড সামলাতে compute সাইজ করুন।

৯.৩ N+1 নিয়ম

একটি ক্লাস্টারড পরিবেশে সবসময় এমনভাবে ডিজাইন করুন যাতে একটি নোড ব্যর্থ হলে বাকি নোডগুলো স্বাভাবিক ওয়ার্কলোডের ১০০% সামলাতে পারে — শুধু টিকে থাকা নয়, গ্রহণযোগ্যভাবে পারফর্ম করা। স্বাভাবিক লোড সামলাতে যদি দুটি RAC নোড দরকার হয়, তিনটি ডিপ্লয় করুন — যাতে একটি নোড ব্যর্থ হলেও আপনার হাতে পূর্ণ ধারণক্ষমতার দুটি নোড থাকে।

১০. ডকুমেন্টেশন ডেলিভারেবল

একটি সম্পূর্ণ আইটি অবকাঠামো ডিজাইন এনগেজমেন্ট এমন একগুচ্ছ ডকুমেন্ট তৈরি করে যা পরিবেশের জন্য নির্ভরযোগ্য রেফারেন্স হিসেবে কাজ করে:

• High-Level Design (HLD): আর্কিটেকচার ডায়াগ্রাম, প্রযুক্তি সিদ্ধান্ত ও ডিজাইনের যুক্তি — ম্যানেজমেন্ট পর্যালোচনা ও অনুমোদনের উপযোগী
• Low-Level Design (LLD): বিস্তারিত স্পেসিফিকেশন — IP অ্যাড্রেস স্কিম, VLAN বরাদ্দ, স্টোরেজ লেআউট, Oracle প্যারামিটার, RAC কনফিগারেশন, Data Guard সেটআপ
• Bill of Materials (BOM): প্রয়োজনীয় হার্ডওয়্যার, সফটওয়্যার লাইসেন্স ও নেটওয়ার্ক সরঞ্জাম — vendor-neutral স্পেসিফিকেশনসহ যাতে প্রকিউরমেন্ট প্রতিযোগিতামূলক কোট পেতে পারে
• Implementation Runbook: ধাপে ধাপে ইনস্টলেশন ও কনফিগারেশন প্রক্রিয়া — পুনরুৎপাদনযোগ্য, টেস্টেড, সাইন-অফ করা
• DR Runbook: Failover ও failback প্রক্রিয়া — টেস্টেড, সময় মাপা, এবং প্রয়োজনের মুহূর্তের জন্য প্রস্তুত
• Capacity Review Schedule: প্রবৃদ্ধি পরিকল্পনার বিপরীতে পর্যালোচনার জন্য ত্রৈমাসিক মেট্রিক

১১. বাংলাদেশি প্রতিষ্ঠানে সাধারণ অবকাঠামো ভুল

বাংলাদেশ ও আন্তর্জাতিকভাবে একাধিক শিল্পে কাজ করে এগুলোই সবচেয়ে বেশি সমস্যা সৃষ্টিকারী অবকাঠামো সিদ্ধান্ত যা আমি দেখি:

• ERP ডেটাবেজের জন্য একক সার্ভার: কোনো স্তরে রিডানডেন্সি নেই — একটি হার্ডওয়্যার ব্যর্থতা সবকিছু অফলাইন করে
• একই সার্ভারে ব্যাকআপ: ব্যাকআপ যে সার্ভারে আছে সেটিই যদি ব্যর্থ হয় বা পুড়ে যায়, তবে ব্যাকআপ অকেজো
• কোনো DR সাইট নেই: "আমাদের ব্যাকআপ আছে" কোনো DR কৌশল নয় — ব্যাকআপ থেকে রিস্টোর করতে ঘণ্টা লাগে; স্ট্যান্ডবাইয়ে failover-এ মিনিট লাগে
• আন্ডারসাইজড স্টোরেজ IOPS: যথেষ্ট ডিস্ক স্পেস কিন্তু লেনদেনের হারের জন্য ডিস্ক খুব ধীর — লোডের নিচে পারফরম্যান্স নেমে যায়
• একক ইন্টারনেট সংযোগ: রিমোট অ্যাক্সেস, ক্লাউড সেবা ও পার্টনার ইন্টিগ্রেশনের জন্য ইন্টারনেট আপটাইম গুরুত্বপূর্ণ — এক ঘণ্টা ডাউনটাইমের চেয়ে দ্বিতীয় প্রোভাইডারের খরচ কম
• অটেস্টেড DR: যে DR পরিকল্পনা কখনও টেস্ট করা হয়নি তা DR পরিকল্পনা নয় — তা একটি আশা। ন্যূনতম বছরে একবার, আদর্শভাবে প্রতি ৬ মাসে failover টেস্ট করুন
• কোনো ক্যাপাসিটি মনিটরিং নেই: স্টোরেজ ভরে যায়, CPU ৯৫%-এ পৌঁছায়, রেসপন্স টাইম নামে — আর সমস্যা হয়ে ওঠার আগে কেউ খেয়ালই করে না

১২. কোথা থেকে শুরু: অবকাঠামো মূল্যায়ন

নতুন অবকাঠামো ডিজাইনের আগে আমি যে প্রতিটি এনগেজমেন্ট নিই তা বর্তমান অবস্থার একটি সৎ মূল্যায়ন দিয়ে শুরু হয়:

• বর্তমান পরিবেশে single points of failure কোনগুলো?
• RTO ও RPO চাহিদা কী — এবং বর্তমান অবকাঠামো আসলে যা দিতে পারে তার সাথে কি তা মেলে?
• আগামী ৩ বছরে কী প্রবৃদ্ধি পরিকল্পিত — নতুন সাইট, নতুন ইউজার, নতুন সিস্টেম?
• কোন কমপ্লায়েন্স ও রেগুলেটরি চাহিদা নির্দিষ্ট আর্কিটেকচার সিদ্ধান্ত চালিত করে?
• কী বাজেট পরিসীমা আছে — এবং আমরা কীভাবে সর্বোচ্চ-ঝুঁকির ফাঁকগুলো আগে অগ্রাধিকার দেব?

ভালো অবকাঠামো ডিজাইন একসাথে প্রতিটি বেস্ট প্র্যাকটিস বাস্তবায়ন নয়। এটি প্রতিষ্ঠানের ঝুঁকি প্রোফাইল বোঝা এবং ব্যবসায়িক প্রভাবের ক্রমে সর্বোচ্চ-ঝুঁকির ফাঁকগুলো ধাপে ধাপে বন্ধ করা।

মূল্যায়ন শেষ হলে প্রতিটি HA/DR এনগেজমেন্টে আমি আসলে এই ডিজাইন ক্রমটিই অনুসরণ করি:

1. ব্যবসার সাথে মিলে RPO ও RTO নির্ধারণ করুন — কোনো হার্ডওয়্যার নিয়ে আলোচনার আগেই কতটা ডেটা ক্ষতি ও ডাউনটাইম গ্রহণযোগ্য তার ওপর ম্যানেজমেন্টের লিখিত সাইন-অফ নিন।
2. Single points of failure ম্যাপ করুন — প্রতিটি স্তর (compute, storage, network, database, application) ধরে হেঁটে তালিকা করুন কোনটি একা ব্যর্থ হলে সেবা ভেঙে পড়ে।
3. প্রাইমারি সাইটের ভেতরে HA ডিজাইন করুন — আপটাইম লক্ষ্য পূরণে রিডানডেন্ট পাওয়ার, NIC, সুইচ, স্টোরেজ পাথ ও ক্লাস্টারিং (RAC, WebLogic cluster)।
4. সেকেন্ডারি সাইটে DR ডিজাইন করুন — সাইন-অফ করা RPO/RTO পূরণ করে এমন Data Guard protection mode ও রেপ্লিকেশন ব্যান্ডউইথ বেছে নিন।
5. ব্যাকআপ স্তর স্বাধীনভাবে ডিজাইন করুন — দুই সাইটেই আলাদা মিডিয়ায় RMAN; ব্যাকআপ হলো শেষ প্রতিরক্ষা লাইন, DR-এর বিকল্প নয়।
6. ডকুমেন্ট করুন, বাস্তবায়ন করুন এবং সত্যিকারের failover টেস্ট করুন — HLD/LLD, runbook, তারপর go-live-এর আগে একটি সময়-মাপা failover টেস্ট এবং এরপর নির্দিষ্ট সময়সূচিতে নিয়মিত টেস্ট।

সাধারণ জিজ্ঞাসা (FAQ)

High availability ও disaster recovery-এর মধ্যে পার্থক্য কী?

High availability একটি সাইটের ভেতরে কম্পোনেন্ট ব্যর্থতা থেকে সুরক্ষা দেয় — একটি মৃত সার্ভার, ডিস্ক বা সুইচ — রিডানডেন্সি ব্যবহার করে, যাতে সেবা চালু থাকে। Disaster recovery পুরো সাইট হারানোর বিরুদ্ধে সুরক্ষা দেয় — আগুন, বন্যা, র‍্যানসমওয়্যার, দীর্ঘ বিদ্যুৎ বিভ্রাট — আপনার সিস্টেমের সিঙ্ক্রোনাইজড কপিসহ একটি দ্বিতীয় লোকেশন ব্যবহার করে। দুটোই দরকার: HA প্রতিদিনের হার্ডওয়্যার ব্যর্থতার মধ্যেও আপনাকে অনলাইন রাখে, আর পুরো প্রাইমারি সাইট চলে গেলে DR ব্যবসাকে ফিরিয়ে আনে।

আমার প্রতিষ্ঠানের কোন RPO ও RTO লক্ষ্য করা উচিত?

এটি নির্ভর করে এক ঘণ্টার হারানো ডেটা ও এক ঘণ্টার ডাউনটাইম ব্যবসার আসলে কত ক্ষতি করে তার ওপর — আগে সেটি হিসাব করুন, তারপর তার সাথে মেলে এমন আর্কিটেকচার কিনুন। ব্যবহারিক শুরুর বিন্দু হিসেবে: একটি মাঝারি আকারের ERP সাধারণত প্রায়-শূন্য থেকে ১৫ মিনিটের RPO (Data Guard async) এবং ৩০–৬০ মিনিটের RTO-র যৌক্তিকতা দেয়; ব্যাংকিং ও পেমেন্ট সিস্টেমে দরকার শূন্য ডেটা ক্ষতি (synchronous replication) এবং মিনিটের মধ্যে RTO। ডিফল্টভাবে শূন্য/শূন্য লক্ষ্য করবেন না — শূন্যের দিকে প্রতিটি ধাপ খরচ প্রায় দ্বিগুণ করে।

একটিমাত্র সার্ভারে ERP চালানোর ঝুঁকি কী?

সবকিছু একসাথে ব্যর্থ হয়: একটি মাদারবোর্ড, RAID কন্ট্রোলার বা পাওয়ার সাপ্লাই ব্যর্থতা ডেটাবেজ, অ্যাপ্লিকেশন এবং প্রায়ই ব্যাকআপকেও একসাথে অফলাইন করে দেয়। পুনরুদ্ধার মানে হার্ডওয়্যার সংগ্রহ, পুনরায় ইনস্টল এবং ব্যাকআপ থেকে রিস্টোর — সাধারণত এক থেকে তিন দিনের সম্পূর্ণ আউটেজ, সাথে শেষ ভালো ব্যাকআপ পর্যন্ত ডেটা ক্ষতি। আমার অভিজ্ঞতায় এটিই বাংলাদেশের প্রতিষ্ঠানগুলোতে সবচেয়ে সাধারণ — এবং সবচেয়ে এড়ানো সম্ভব — অবকাঠামো ঝুঁকি।

ক্লাউড DR কখন অর্থবহ?

ক্লাউড DR যুক্তিসঙ্গত যখন আপনি দ্বিতীয় একটি ভৌত ফ্যাসিলিটির খরচ যৌক্তিক করতে পারেন না — এটি DR সাইটকে ক্যাপিটাল খরচ থেকে মাসিক খরচে রূপান্তর করে, আর ক্যাপাসিটি ছোট আকারে বসে থাকতে পারে যতক্ষণ না দুর্যোগ সেটি বড় করে। এটি অ্যাপ্লিকেশন টিয়ার এবং ক্লাউড compute-এ Data Guard standby-র জন্য ভালো কাজ করে। আগে তিনটি বিষয় যাচাই করুন: ডেটা রেসিডেন্সি ও রেগুলেটরি নিয়ম, রেপ্লিকেশন হালনাগাদ রাখতে প্রয়োজনীয় ব্যান্ডউইথ, এবং failover-এর পরে আপনার সব ডেটা আবার বের করে আনার প্রকৃত খরচ।

আমাদের কত ঘন ঘন DR failover টেস্ট করা উচিত?

ন্যূনতম বছরে একবার, আদর্শভাবে প্রতি ছয় মাসে — এবং টেস্টটি হতে হবে একটি প্রকৃত failover, যেখানে standby আসলেই কিছু সময়ের জন্য প্রোডাকশন ট্রাফিক সেবা দেয়, নিছক চেকলিস্ট পর্যালোচনা নয়। প্রতিটি ধাপের সময় আপনার RTO লক্ষ্যের বিপরীতে মাপুন, কী ভাঙল তা নথিভুক্ত করুন এবং runbook ঠিক করুন। অটেস্টেড DR পরিকল্পনা একটি আশা, পরিকল্পনা নয়; আমি যেসব প্রথম টেস্ট দেখেছি তার প্রায় অর্ধেকে এমন একটি ব্লকিং সমস্যা বেরিয়ে এসেছে যা কেউ জানত না।

High availability-র জন্য কি আমার Oracle RAC দরকার, নাকি Data Guard-ই যথেষ্ট?

সবসময় নয়। RAC একটি সাইটের ভেতরে প্রায়-শূন্য-ডাউনটাইম নোড failover দেয়, কিন্তু খরচ ও অপারেশনাল জটিলতা যোগ করে। অনেক মাঝারি আকারের ওয়ার্কলোডের জন্য Fast-Start Failover-সহ Data Guard দিয়ে সুরক্ষিত একটি single instance RAC-এর খরচের ভগ্নাংশে ৩০–৬০ সেকেন্ডের failover দেয় — RAC-এর সাথে পার্থক্য মিনিট বনাম সেকেন্ড। আমি RAC সুপারিশ করি যখন ব্যবসা সত্যিই সংক্ষিপ্ত বিঘ্নও সহ্য করতে পারে না, অথবা এক সার্ভারের ক্ষমতার বাইরে স্কেল করা দরকার।

শেষ কথা

অবকাঠামো ডিজাইন একটি প্রতিষ্ঠান করতে পারে এমন সর্বোচ্চ-লিভারেজ বিনিয়োগগুলোর একটি। একটি সুপরিকল্পিত পরিবেশ নীরবে পটভূমিতে চলে, অদৃশ্যভাবে প্রতিটি ব্যবসায়িক কার্যক্রমকে সমর্থন করে। একটি দুর্বল পরিকল্পিত পরিবেশ সংকট, খরচ ও সুনামের ঝুঁকির পুনরাবৃত্ত উৎস হয়ে ওঠে।

যেসব প্রতিষ্ঠানের সাথে আমি কাজ করেছি এবং যারা সঠিক HA + DR আর্কিটেকচারে বিনিয়োগ করে তারা খুব কমই জরুরি অবস্থায় আমাকে ডাকে। যারা সেই বিনিয়োগ পেছায় — কারণ যতক্ষণ না মরিয়াভাবে প্রয়োজন হয় ততক্ষণ এটি ব্যয়বহুল মনে হয় — তারা শেষ পর্যন্ত জরুরি পুনরুদ্ধার, হারানো উৎপাদন ও ব্যবসায়িক প্রভাবে ডিজাইনের চেয়ে অনেক বেশি খরচ করে।

আপনার প্রতিষ্ঠান যদি এমন অবকাঠামোতে গুরুত্বপূর্ণ সিস্টেম চালায় যা কখনও উপলব্ধতা ও পুনরুদ্ধারের জন্য সঠিকভাবে ডিজাইন করা হয়নি, তবে সেটি সমাধানের সেরা সময় ব্যর্থতা ঘটার আগে।