Oracle 19c RAC: Real Application Clusters গভীরভাবে

Oracle Real Application Clusters (RAC) হলো active-active ডেটাবেজ উচ্চ availability-র সোনালি মানদণ্ড। একাধিক দেশে ব্যাংকিং, ফার্মা ও সফটওয়্যার-প্রোডাক্ট ক্লায়েন্টদের জন্য 19c RAC ক্লাস্টার ডিপ্লয় ও পরিচালনার পর আমি আত্মবিশ্বাসের সঙ্গে বলতে পারি: ঠিকভাবে কনফিগার করলে RAC এমন zero-downtime আর্কিটেকচার দেয় যার সঙ্গে অন্য কোনো ডেটাবেজ প্রযুক্তি টেক্কা দিতে পারে না। RAC-তে প্রথম কাজ শুরু করার সময় এমন একটি বিস্তারিত টেকনিক্যাল গাইড আমি খুঁজেছিলাম যা তখন ছিল না — এটি সেই গাইড।

১. Oracle RAC কী এবং কেন ব্যবহার করবেন?

Oracle RAC-এর মাধ্যমে ভিন্ন ভিন্ন physical/virtual সার্ভারে থাকা একাধিক Oracle instance একটিমাত্র shared ডেটাবেজে অ্যাক্সেস করতে পারে। প্রতিটি instance — নিজের node-এ চলে — তার নিজস্ব মেমরি (SGA), background process ও রিসোর্স রাখে, কিন্তু সবাই shared storage-এ (ASM disk group) সংরক্ষিত একই datafile সেট থেকে পড়ে ও তাতে লেখে।

পার্থক্যটা গুরুত্বপূর্ণ: এটি একটিই ডেটাবেজ, অনেকগুলো instance। পাওয়ার বোতাম টিপে একটি node মেরে ফেলুন — অ্যাপ্লিকেশন টিকে থাকা node গুলোতে চলতেই থাকবে, কারণ ডেটা কখনোই ওই node-এর "ভেতরে" ছিল না। নার্ভাস আইটি ডিরেক্টরদের সামনে ঠিক এই জিনিসটাই আমি একাধিকবার করে দেখিয়েছি — লাইভ node-এর প্লাগ টেনে খোলা আজও আমার জানা সবচেয়ে বিশ্বাসযোগ্য RAC সেলস পিচ।

কেন RAC ডিপ্লয় করবেন?

• উচ্চ availability: একটি node ব্যর্থ হলে টিকে থাকা node গুলো স্বচ্ছভাবে ডেটাবেজ সেবা দিতে থাকে
• স্কেলেবিলিটি: বেড়ে যাওয়া লোড সামলাতে আরও node যোগ করুন
• লোড ব্যালান্সিং: SCAN listener ও service-এর মাধ্যমে workload স্বয়ংক্রিয়ভাবে বণ্টিত হয়
• Zero-downtime প্যাচিং: এক এক করে node-এ rolling patch প্রয়োগ
• হার্ডওয়্যার ব্যবহার: সব node সক্রিয় — কোনো অলস standby-র অপচয় নেই

২. RAC আর্কিটেকচার: সামগ্রিক চিত্র

একটি সাধারণ ২-node Oracle 19c RAC-তে এই উপাদানগুলো থাকে:

• দুই বা ততোধিক node (physical সার্ভার বা VM) যারা একই OS চালায়
• Shared Storage — SAN বা NAS, সব node থেকে দৃশ্যমান
• Private Interconnect — cache fusion-এর জন্য node গুলোর মধ্যে ডেডিকেটেড নেটওয়ার্ক (10 GbE+)
• Public Network — ক্লায়েন্ট সংযোগ ও SCAN-এর জন্য
• Oracle Grid Infrastructure (GI) — Clusterware + ASM
• Oracle Database 19c — RAC অপশনসহ ইনস্টল করা

প্রতিটি node একটি করে VIP (virtual IP)-ও বহন করে। কোনো node মারা গেলে তার VIP টিকে থাকা একটি node-এ fail over করে এবং সঙ্গে সঙ্গে সংযোগ প্রত্যাখ্যান করতে শুরু করে — ফলে ক্লায়েন্ট মিনিটের পর মিনিট TCP timeout-এ ঝুলে না থেকে দ্রুত একটি "connection refused" পায়। ছোট্ট একটা খুঁটিনাটি, কিন্তু failover কত দ্রুত অনুভূত হয় তাতে বিশাল পার্থক্য গড়ে দেয়।

৩. Oracle Grid Infrastructure: ভিত্তি

RAC ইনস্টল করার আগে আপনাকে Oracle Grid Infrastructure 19c ইনস্টল করতে হবে। GI দুটি গুরুত্বপূর্ণ সেবা দেয়:

৩.১ Oracle Clusterware (CRS)

Clusterware হলো সেই সফটওয়্যার স্তর যা একাধিক সার্ভারকে একটি একক cluster হিসেবে কাজ করতে দেয়। মূল উপাদানগুলো:

• Cluster Ready Services (CRS): cluster রিসোর্স সমন্বয়কারী master daemon
• Cluster Synchronization Services (CSS): voting disk ব্যবহার করে node সদস্যপদ পর্যবেক্ষণ করে
• Event Manager (EVM): cluster event প্রকাশ করে
• Oracle Notification Service (ONS): ক্লায়েন্টদের কাছে alert বিতরণ করে
• ohasd: প্রথম চালু হওয়া daemon; বাকি সবকিছু bootstrap করে

Cluster status যাচাই করা হয় এভাবে:

crsctl check cluster -all
crsctl status resource -t
crsctl status server
olsnodes -n -i -s

কমান্ড জানা কাজের অর্ধেক — output পড়তে পারা বাকি অর্ধেক। একটি সুস্থ ২-node cluster-এ olsnodes -n -i -s -t আপনাকে যা দেয়:

$ olsnodes -n -i -s -t
racnode1   1   racnode1-vip   Active   Unpinned
racnode2   2   racnode2-vip   Active   Unpinned

আমি যা দেখি: প্রতিটি node-এ Active লেখা থাকতে হবে। কোনো node যদি Inactive দেখায়, সেটি cluster ছেড়ে চলে গেছে — অন্য কিছু করার আগে ওই node-এর ocssd লগ পড়তে যান। সংখ্যাটি হলো node ID (trace file-এ ব্যবহৃত হয়), আর "Unpinned" 19c-তে স্বাভাবিক।

crsctl check cluster -all-এর ক্ষেত্রে আমি প্রতি node-এ তিনটি "online" লাইন চাই:

$ crsctl check cluster -all
**************************************************************
racnode1:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************
racnode2:
CRS-4537: Cluster Ready Services is online
...

কোনো node-এ CSS online কিন্তু CRS offline — এটি একটি ক্লাসিক প্যাটার্ন: node টি cluster-এর ভেতরেই আছে, কিন্তু তার রিসোর্সগুলো চালু হয়নি — সাধারণত কোনো resource dependency ব্যর্থতা বা ASM সমস্যা। আর crsctl status resource -t-তে টেক্সটের দেয়াল উপেক্ষা করে STATE কলামে ONLINE নয় এমন যেকোনো কিছু খুঁজুন, সঙ্গে TARGET কলামটিও: TARGET=ONLINE অথচ STATE=OFFLINE মানে clusterware চেষ্টা করছে এবং ব্যর্থ হচ্ছে — ওই resource-টিই আপনার সমস্যার সন্তান।

৩.২ Automatic Storage Management (ASM)

ASM হলো ডেটাবেজ ফাইলের জন্য Oracle-এর volume manager ও file system। এটি shared disk গুলোকে disk group-এ পুল করে, স্বয়ংক্রিয় striping, mirroring ও rebalancing সহ। একটি সাধারণ RAC-তে গুরুত্বপূর্ণ disk group:

• +OCR/VOTING: Cluster registry ও voting disk (NORMAL redundancy = ন্যূনতম ৩টি disk)
• +DATA: Datafile, controlfile, online redo log
• +RECO: Fast Recovery Area — archive log, RMAN backup, flashback log

ASM নিজেই একটি আলাদা লেখার দাবিদার — এবং সেটি আছে: আমার সম্পূর্ণ ASM storage গাইড-এ disk group, redundancy স্তর ও rebalancing গভীরভাবে আলোচনা করা হয়েছে।

৪. SCAN: Single Client Access Name

SCAN হলো Oracle RAC-এর সবচেয়ে মার্জিত ফিচারগুলোর একটি। প্রতিটি node-এর IP জানার বদলে ক্লায়েন্ট একটিমাত্র DNS নামে (যেমন prod-scan.company.com) সংযুক্ত হয়, যা round-robin ভিত্তিতে ৩টি SCAN IP-তে resolve করে। cluster node গুলো জুড়ে তিনটি SCAN listener চলে, ক্লায়েন্ট সংযোগ গ্রহণ করে এবং service registration ও লোড অনুযায়ী উপযুক্ত node-এ রুট করে।

সুবিধা: node যোগ/অপসারণ করলে ক্লায়েন্টের কোনো কনফিগারেশন বদলাতে হয় না। একটি node যোগ করলেন? সেটি স্বয়ংক্রিয়ভাবে SCAN-এর সঙ্গে register হয়ে যায়।

৫. Voting Disk ও OCR

• Voting Disk: cluster সদস্যপদ সিদ্ধান্তের জন্য ব্যবহৃত হয়। কোনো node যদি অধিকাংশ voting disk-এ অ্যাক্সেস হারায়, split-brain রোধে সেটিকে evict (reboot) করা হয়। NORMAL redundancy-র জন্য ন্যূনতম ৩টি voting disk।
• Oracle Cluster Registry (OCR): cluster কনফিগারেশন মেটাডেটা সংরক্ষণ করে — node তালিকা, service, রিসোর্স। প্রতি ৪ ঘণ্টা অন্তর স্বয়ংক্রিয়ভাবে backup নেওয়া হয়।

৬. Cache Fusion: RAC কীভাবে সামঞ্জস্য বজায় রাখে

এটিই RAC-এর জাদু। যখন Node A একটি block পরিবর্তন করে, Node B-র সর্বশেষ সংস্করণ দরকার হয়। disk-এ লিখে তারপর পড়ার বদলে RAC Cache Fusion ব্যবহার করে private interconnect-এর মাধ্যমে সরাসরি instance গুলোর মধ্যে block পাঠিয়ে দেয়। Global Cache Service (GCS) মালিকানা সমন্বয় করে; Global Enqueue Service (GES) node জুড়ে lock পরিচালনা করে।

একটি block transfer-এর গল্পটা এবার হাতে-কলমে শুনুন। Instance 1-এর এক ব্যবহারকারী invoice-এর 4711 নম্বর row-এর বিপরীতে একটি UPDATE চালালেন; row টি যে block-এ আছে সেটি রয়েছে instance 2-এর buffer cache-এ, dirty অবস্থায়, কারণ সেখানে কেউ সদ্য পাশের একটি row বদলেছেন। Instance 1 ওই block-এর master-কে (ওই block-এর দায়িত্বপ্রাপ্ত GCS process — যেকোনো instance-এ থাকতে পারে) জিজ্ঞেস করে: "block টা কার কাছে?" Master তখন instance 2-কে বলে: তোমার বর্তমান কপিটা instance 1-এ পাঠাও। Instance 2 interconnect দিয়ে block পাঠায়, নিজের কপিটি downgrade করে, আর instance 1 এখন বর্তমান সংস্করণটি হাতে পেয়ে তার পরিবর্তনটি করে।

পুরো লেনদেনে মোট disk I/O: শূন্য। Instance 1-এর ব্যবহারকারী gc current block 3-way-এর মতো একটি wait event দেখেন — "3-way" কারণ তিনটি instance জড়িত ছিল (requester, master, holder)। ২-node cluster-এ আপনি কখনোই 2-way-এর বেশি দেখবেন না, আর cluster যত বড়ই হোক, কোনো transfer কখনোই ৩ hop-এর বেশি নেয় না — এটি একটি সচেতন ডিজাইন সীমা।

AWR পড়ার সময় আমি যে অভিজ্ঞতালব্ধ নিয়মটি ব্যবহার করি: প্রতি gc block transfer-এ কয়েক মিলিসেকেন্ড — সুস্থ। কিন্তু gc cr block busy বা gc buffer busy acquire যখন আপনার top-5 wait-এ উঠে আসে, তখন instance গুলো একই block নিয়ে কাড়াকাড়ি করছে — সেটি অ্যাপ্লিকেশনের locality সমস্যা, নেটওয়ার্ক সমস্যা নয়, এবং কোনো switch upgrade-ই তা সারাবে না।

৬.১ Private Interconnect: RAC প্রজেক্ট যেখানে হোঁচট খায়

এই কারণেই low-latency private interconnect নিয়ে কোনো আপস চলে না। ন্যূনতম 10 GbE, আদর্শভাবে high-throughput সিস্টেমের জন্য 25 GbE বা InfiniBand। তবে bandwidth হলো বিজ্ঞাপনের সংখ্যা; আসলে যা কষ্ট দেয় তা হলো latency আর isolation। বাস্তব ডিপ্লয়মেন্টে আমার হোঁচট খাওয়া ফাঁদগুলো:

• Shared switch। এক নেটওয়ার্ক টিম আমাদের "private" interconnect-কে backup VLAN-এর সঙ্গে একই switch fabric-এর ভেতর দিয়ে চালিয়েছিল। প্রতি রাতে backup-এর সময় gc wait তিনগুণ হয়ে যেত। Interconnect-কে physically ডেডিকেটেড হতে হবে — নিজস্ব switch, বা অন্তত কঠোরভাবে isolated, non-routable একটি VLAN।
• ভুল MTU। Jumbo frame (MTU 9000) Cache Fusion-কে সাহায্য করে, কারণ একটি database block একটি frame-এই এঁটে যায় — কিন্তু কেবল তখনই যদি পথের প্রতিটি port একমত হয়। একটি switch port 1500-এ রয়ে গেলে fragmentation হয়, আর এমন রহস্যময়, থেমে-থেমে-আসা ধীরগতি জন্মায় যা খুঁজে বের করতে সপ্তাহ লেগে যায়।
• পথের মাঝে firewall। RAC node গুলোর মাঝে কেউ firewall বা inspection ডিভাইস বসালে eviction অবধারিত। Heartbeat ট্রাফিককে শূন্য হস্তক্ষেপে চলতে দিতে হবে।
• Redundancy না থাকা। HAIP সহ দুটি interconnect NIC ব্যবহার করুন (একাধিক private network register করলে GI থেকেই Oracle এটি স্বয়ংক্রিয়ভাবে দেয়)। একটিমাত্র NIC মানে একটি ক্যাবল-টানেই eviction।

Cluster আসলে কী ব্যবহার করছে তা যাচাই করুন — ডিজাইন ডকুমেন্ট কী বলছে তা নয়:

$ oifcfg getif
ens192  10.10.1.0    global  public
ens224  192.168.77.0 global  cluster_interconnect,asm

SQL> SELECT name, ip_address FROM v$cluster_interconnects;
NAME     IP_ADDRESS
-------- ---------------
ens224   169.254.14.209   -- HAIP address: good sign

৭. Oracle 19c RAC ইনস্টল করা — উচ্চ-স্তরের ধাপ

1. পূর্বশর্ত: OS (Oracle Linux 7/8), shared storage কনফিগার করা, time sync (chrony/NTP), SCAN-এর জন্য DNS, swap, hugepages
2. node গুলোর মধ্যে SSH user equivalence কনফিগার করুন oracle ও grid ইউজারের জন্য
3. cluster verification চালান: ./runcluvfy.sh stage -pre crsinst -n node1,node2 -fixup
4. Grid Infrastructure 19c ইনস্টল করুন OUI (gridSetup.sh)-এর মাধ্যমে — "Configure Oracle Grid Infrastructure for a New Cluster" বেছে নিন
5. ASM disk group তৈরি করুন OCR/VOTING, DATA, RECO-র জন্য
6. Oracle Database 19c software only ইনস্টল করুন oracle ইউজার হিসেবে
7. RAC ডেটাবেজ তৈরি করুন DBCA দিয়ে — RAC database template বেছে নিন
8. cluster health যাচাই করুন crsctl status resource -t দিয়ে
9. সর্বশেষ Release Update প্যাচ প্রয়োগ করুন (সবসময় সর্বশেষ RU চালান)

একটি অভ্যাস আমাকে বারবার বাঁচিয়েছে: runcluvfy.sh এড়িয়ে যাবেন না, আর installer আপনাকে এগোতে দিচ্ছে বলেই এর warning গুলো উপেক্ষা করবেন না। আমি উদ্ধার করেছি এমন প্রায় প্রতিটি যন্ত্রণাদায়ক RAC ইনস্টলের মূলে ছিল কারও ক্লিক করে পার হয়ে যাওয়া একটি cluvfy warning — সাধারণত DNS, time sync, বা কোনো অনুপস্থিত kernel parameter।

৮. অপরিহার্য RAC ম্যানেজমেন্ট কমান্ড

এগুলো আয়ত্ত করুন — এগুলোই আপনার প্রতিদিনের সঙ্গী:

# Cluster health
crsctl check cluster -all
crsctl status resource -t

# Database management
srvctl status database -d MYDB
srvctl start database -d MYDB
srvctl stop database -d MYDB -o immediate
srvctl config database -d MYDB

# Instance management
srvctl start instance -d MYDB -i MYDB1
srvctl stop instance -d MYDB -i MYDB2 -o transactional

# Services
srvctl add service -d MYDB -s OLTP -preferred MYDB1,MYDB2
srvctl start service -d MYDB -s OLTP
srvctl status service -d MYDB

# SCAN and listeners
srvctl status scan
srvctl status scan_listener
lsnrctl status LISTENER_SCAN1

# ASM
asmcmd lsdg
sqlplus / as sysasm
SELECT name, state, total_mb, free_mb FROM v$asm_diskgroup;

srvctl status database পড়ার একটি টিপস: এই output বলে instance গুলো কোথায় চলছে, সেগুলো সুস্থ কি না তা নয়। একটি আংশিক outage দেখতে এমন হয়:

$ srvctl status database -d MYDB
Instance MYDB1 is running on node racnode1
Instance MYDB2 is not running on node racnode2

srvctl-এ "is not running" অথচ crsctl-এ node-টি ONLINE — এর মানে cluster ঠিকই আছে কিন্তু instance টি মারা গেছে — clusterware লগ নয়, instance-এর alert লগ দেখুন। আর যদি srvctl ও crsctl দুটোই দেখায় node টি নেই, তাহলে উল্টো দিক থেকে এগোন: আগে OS, নেটওয়ার্ক, storage। এই একটিমাত্র পার্থক্যই RAC triage-এর ৮০% সঠিক পথে পাঠিয়ে দেয়।

srvctl config database -d MYDB-ও মুখস্থ করে ফেলুন। এটি দেখায় spfile-এর অবস্থান, password file, disk group আর কনফিগার করা service গুলো — রাত ২টায় যখন কিছুই start হচ্ছে না এবং cluster-টা কীভাবে বানানো হয়েছিল মনে পড়ছে না, তখন ঠিক এই তথ্যগুলোই আপনার দরকার।

৯. Service, TAF ও Application Continuity: এমন failover যা ব্যবহারকারী টেরই পান না

ব্যবহারকারীরা টের না পেয়েই একটি অ্যাপ্লিকেশন কীভাবে node crash থেকে বেঁচে যায়? Service-এর মাধ্যমে। Service হলো ডেটাবেজে ঢোকার একটি নামকরণ করা প্রবেশপথ, যাকে clusterware instance গুলোর মধ্যে সরাতে পারে। ক্লায়েন্ট SCAN দিয়ে service-এ সংযুক্ত হয় — কখনও instance-এ নয় — ফলে কোনো node মারা গেলে service টি টিকে থাকা node-এ চালু হয়ে যায় এবং নতুন সংযোগগুলো এমনিতেই সেখানে পড়ে। চলমান সংযোগগুলো সামলায় TAF বা Application Continuity।

# A service preferring node 1, failing over to node 2
srvctl add service -d MYDB -s ERP_OLTP \
  -preferred MYDB1 -available MYDB2 \
  -failovertype AUTO -commit_outcome TRUE \
  -failoverretry 3 -failoverdelay 5 -notification TRUE

srvctl start service -d MYDB -s ERP_OLTP

failover সুরক্ষার তিনটি স্তর, জাদুর ঊর্ধ্বক্রমে:

• Connect-time failover: নতুন সংযোগ টিকে থাকা node-এ যায়। SCAN + service-এর সঙ্গে বিনামূল্যে পাওয়া। চলমান session গুলো মারা যায়।
• TAF (Transparent Application Failover): ব্যর্থ SELECT অন্য node-এ স্বয়ংক্রিয়ভাবে replay হতে পারে। চলমান transaction তবু rollback হয় — TAF query রক্ষা করে, DML নয়।
• Application Continuity (AC): 19c যুগের উত্তর। Driver session-এর কাজ রেকর্ড করে এবং চলমান transaction টিকে থাকা node-এ REPLAY করে। ঠিকঠাক করলে transaction-এর মাঝপথে node crash অদৃশ্য — ব্যবহারকারীর commit অন্য node-এ সফল হয়।

মাঠপর্যায়ের সৎ অভিজ্ঞতা: বেশিরভাগ ERP ও legacy অ্যাপ্লিকেশন সাদামাটা service + connect-time failover-এই দিব্যি চলে, কারণ তাদের connection pool এমনিতেই ভদ্রভাবে reconnect করে। আমি AC-র দিকে হাত বাড়াই তখন, যখন ব্যবসা সত্যিই একটি rollback হওয়া transaction সহ্য করতে পারে না — payment posting, ফার্মা ম্যানুফ্যাকচারিংয়ে batch release। এতে driver সাপোর্ট (JDBC replay driver, ODP.NET) ও টেস্টিং লাগে, তাই একে checkbox নয়, একটি প্রজেক্ট হিসেবে নিন।

আরেকটি service কৌশল আমি অনবরত ব্যবহার করি: আলাদা workload-এর জন্য আলাদা service। ERP_OLTP দুই node-এই preferred, REPORTS শুধু node 2-তে preferred। মুহূর্তেই workload isolation — মাস-শেষের রিপোর্টিং ঝড় আপনার order-entry ব্যবহারকারীদের node থেকে দূরে থাকে।

১০. RAC প্যাচিং: Rolling Update

RAC-এর সবচেয়ে বড় জয়গুলোর একটি — zero downtime-এ এক এক করে node-এ প্যাচ প্রয়োগ করুন:

1. Node 1 থেকে সংযোগ drain করুন (service relocate করুন)
2. Node 1-এ service ও instance বন্ধ করুন
3. Node 1-এ OPatch / OPatchAuto প্রয়োগ করুন
4. Node 1 চালু করুন, service ফিরিয়ে relocate করুন
5. Node 2 (ও অন্যান্য)-এর জন্য পুনরাবৃত্তি করুন

সবসময় প্যাচ আগে non-prod RAC-তে পরীক্ষা করুন। ত্রৈমাসিক Release Update (RU) সুপারিশ করা হয় — আমার সম্পূর্ণ প্যাচিং workflow আছে OPatch ও datapatch গাইডে।

১১. ১৮ বছরের প্রোডাকশন থেকে RAC বেস্ট প্র্যাকটিস

• সবসময় ASM ব্যবহার করুন — datafile-এর জন্য raw device বা NFS নয়। 19c-তে ASMLib-এর চেয়ে ASM Filter Driver (AFD) বেশি পছন্দনীয়।
• নেটওয়ার্ক আলাদা করুন: Public + Private (interconnect) ভিন্ন switch-এ
• redundancy-র জন্য private interconnect bonding ব্যবহার করুন (HAIP আপনাকে এটি দেয়)
• Hugepages: সম্পূর্ণ SGA-র জন্য কনফিগার করুন — পারফরম্যান্স উল্লেখযোগ্যভাবে বাড়ায়
• Time sync: বাধ্যতামূলক। drift অদ্ভুত eviction ঘটায়। chrony ব্যবহার করুন।
• service ব্যবহার করুন: কখনও সরাসরি instance-এ সংযুক্ত হবেন না। service আপনাকে স্বচ্ছ failover দেয় (TAF/FAN/AC)।
• cluster event পর্যবেক্ষণ করুন: crsctl events ও cluster_interconnects health-এ Enterprise Manager বা কাস্টম alerting সেট করুন।
• আপনার topology ডকুমেন্ট করুন: node নাম, IP, VIP, SCAN, disk group, service — হালনাগাদ diagram রাখুন।
• ত্রৈমাসিক failover drill অনুশীলন করুন। আত্মবিশ্বাস আসে মহড়া থেকে।

১২. সাধারণ RAC সমস্যা ও সমাধান

• Node Eviction: সাধারণত নেটওয়ার্ক বা storage সমস্যা। /var/log/messages, ocssd.log, নেটওয়ার্ক ping time যাচাই করুন।
• ধীর Cache Fusion: interconnect latency যাচাই করুন (oradebug ipc)। "gc cr block 2-way" wait event খুঁজুন।
• Voting Disk হারানো: quorum হারালে cluster বন্ধ হয়ে যায়। crsctl replace votedisk দিয়ে OCR backup থেকে restore করুন।
• ASM ভারসাম্যহীন: কম-লোডের সময় ALTER DISKGROUP DATA REBALANCE POWER 8; চালান।
• OPatch ব্যর্থতা: প্যাচিংয়ের আগে সবসময় opatch lsinventory snapshot দিয়ে ORACLE_HOME backup নিন।

১৩. একটি যুদ্ধকাহিনি: যে Parallel-Query ঝড় একটি node-কে প্রায় evict করে ফেলেছিল

ফার্মাসিউটিক্যাল ম্যানুফ্যাকচারিং ERP চালানো একটি দুই-node 19c RAC-এ একটি ডায়াগনোসিসের গল্প বলি। উপসর্গ: প্রতি মাস-শেষে node 2 হামাগুড়ি দিত, session জমে যেত, আর দুইবার node টি eviction-এর সেকেন্ড কয়েক দূরত্বে পৌঁছে গিয়েছিল — ocssd লগে network heartbeat মিস হওয়ার রেকর্ড, অথচ নেটওয়ার্কে কেউ হাতই দেয়নি।

আসল গল্পটা বলল AWR রিপোর্ট। দুই node-এই top wait: PX Deq event আর gc buffer busy acquire, সঙ্গে interconnect ট্রাফিক স্বাভাবিক baseline-এর কয়েক গুণ। ট্রিগার ছিল মাস-শেষের MRP ও costing রিপোর্ট — ডজনখানেক parallel query একসঙ্গে ছাড়া হতো, আর RAC-এ parallel execution যেহেতু PX slave-দের আনন্দের সঙ্গে node গুলো জুড়ে ছড়িয়ে দেয়, ওই প্রতিটি query তার intermediate result private interconnect দিয়ে চালান করছিল।

Interconnect ছিল saturated। আর এখানেই বিপজ্জনক অংশটা: cluster heartbeat-ও ওই একই তারে চলে। রিপোর্টের ট্রাফিক তারটি ভাসিয়ে দিলে heartbeat প্যাকেট দেরিতে পৌঁছাতে শুরু করল, আর CSS গুনতে শুরু করল eviction-এর দিকে। একটি রিপোর্টিং জব একটি প্রোডাকশন node-কে প্রায় ফেলে দিচ্ছিল — CPU দিয়ে নয়, I/O দিয়ে নয়, বরং সেই নেটওয়ার্ক দিয়ে যার ওপর RAC তার নিজের বেঁচে থাকার জন্য নির্ভর করে।

সমাধান ছিল নীতিতে, হার্ডওয়্যারে নয়। আমরা node 2-তে pin করা একটি ডেডিকেটেড REPORTS service বানালাম, PARALLEL_FORCE_LOCAL=TRUE সেট করলাম যাতে PX slave রা query যেখানে শুরু হয়েছে সেই node-এই থাকে, আর Resource Manager দিয়ে একসঙ্গে চলা parallel statement-এর সংখ্যা বেঁধে দিলাম। মাস-শেষে interconnect ট্রাফিক নেমে এল peak-এর এক-চতুর্থাংশে, আর eviction warning আর কখনও ফেরেনি।

এ থেকে আমি যে শিক্ষাটি বয়ে বেড়াই: RAC-এ interconnect একটি shared অঙ্গ, নিছক একটি নেটওয়ার্ক লিংক নয়। যা কিছু একে ভাসিয়ে দেয় — parallel query, বিশাল cross-instance update, node affinity-হীন বাচাল কোনো অ্যাপ্লিকেশন — তা আসলে পারফরম্যান্স-সমস্যার পোশাক পরা একটি cluster-স্থিতিশীলতার সমস্যা।

১৪. আমার সকালের RAC হেলথ চেক

আমি যে প্রোডাকশন RAC cluster-এর দায়িত্বে থাকি, প্রতিটিতে দিনের প্রথম কফির সঙ্গে একই পাঁচ-মিনিটের চেক চলে। ক্রমানুসারে:

1. Cluster stack: crsctl check cluster -all — প্রতি node-এ তিনটি "online" লাইন, কোনো ব্যতিক্রম নয়।
2. Resource: crsctl status resource -t — ONLINE নয় এমন যেকোনো STATE, আর যেকোনো TARGET/STATE অমিল খুঁজুন।
3. Instance ও service: srvctl status database -d PROD এবং srvctl status service -d PROD — প্রতিটি instance চলছে, প্রতিটি service তার preferred node-এ (কোনো service তার "available" node-এ বসে থাকা মানে এমন একটি failover ঘটেছে যা কেউ আমাকে জানায়নি)।
4. ASM জায়গা: asmcmd lsdg — +DATA ও +RECO-র free space; +RECO ভরে গেলে archiving থেমে যায়, আর থেমে যাওয়া archiver থামিয়ে দেয় খোদ ডেটাবেজকে।
5. Eviction-এর আগাম সংকেত: প্রতিটি node-এ ocssd লগ ও OS message-এ মিস হওয়া heartbeat বা storage path error-এর জন্য tail করুন — প্রকৃত eviction-এর কয়েক দিন আগেই এগুলো দেখা দেয়।
6. Interconnect যাচাই: গত রাতের AWR snapshot থেকে gc wait-এর গড়ে এক ঝলক; সপ্তাহে সপ্তাহে গড় বেড়ে চলা interconnect ঝামেলার সবচেয়ে আগাম সংকেত।
7. Backup: গত রাতের RMAN backup যে node-এ চলেছে সেখানে সফল হয়েছে কি না নিশ্চিত করুন — যে cluster প্রতিটি ব্যর্থতা থেকে বেঁচে যায় কিন্তু যার backup নেই, সেটিও অপেক্ষমাণ এক দুর্যোগ।

একঘেয়ে? সম্পূর্ণ। কিন্তু আমি আজ পর্যন্ত যত সিরিয়াস RAC incident সামলেছি, প্রতিটিই সবার আগে এই সাত জায়গার কোনো একটিতে নিজের জানান দিয়েছিল।

১৫. RAC নাকি Data Guard — নাকি দুটোই?

আপনার কোনটি দরকার? RAC ও Data Guard ভিন্ন ভিন্ন ব্যর্থতার সমাধান। RAC এক data center-এর ভেতরে একটি server মারা যাওয়া থেকে রক্ষা করে: আরেকটি instance আগে থেকেই চলছে, তাই recovery মাপা হয় সেকেন্ডে। Data Guard রক্ষা করে পুরো সাইট হারানো থেকে — আগুন, বন্যা, বিদ্যুৎ, storage corruption — অন্য কোথাও একটি standby ডেটাবেজ রক্ষণাবেক্ষণ করে।

RAC যা পারে না: shared-storage corruption থেকে বাঁচাতে (সব node একই disk ভাগ করে), সাইটব্যাপী outage থেকে, কিংবা আঙুল ফসকে চালানো DROP TABLE থেকে (যা আনন্দের সঙ্গে প্রতিটি instance-এ ছড়িয়ে পড়ে, কারণ ডেটাবেজ একটিই)। Data Guard যা পারে না: নিছক একটি server crash-এর জন্য শূন্য data loss-এ সেকেন্ড-স্তরের failover দিতে, কিংবা সক্রিয় workload-কে একাধিক মেশিনে scale করতে।

দুটোই বছরের পর বছর চালানোর পর আমার সৎ অবস্থান: যদি একটিমাত্র কেনার সামর্থ্য থাকে, Data Guard কিনুন। একটি standby দ্বিতীয় একটি RAC node-এর চেয়ে অনেক বেশি শ্রেণির ব্যর্থতা থেকে রক্ষা করে — লাইসেন্স ও অপারেশনাল জটিলতার এক ভগ্নাংশ খরচে। RAC তার খরচ পোষায় তখন, যখন ডাউনটাইম মাপা হয় প্রতি মিনিটে টাকায় এবং ১০ মিনিটের failover-ও অগ্রহণযোগ্য। আর প্রকৃত অর্থে critical সিস্টেমের জন্য — আমি যে ব্যাংকিং ও ফার্মা কোরগুলো দেখাশোনা করি — উত্তর হলো দুটোই: primary সাইটের ভেতরে RAC, দ্বিতীয় সাইটে Data Guard। এই সমন্বয়ই Oracle-এর নিজস্ব Maximum Availability Architecture, আর ব্যবসা যখন সত্যিই থামতে পারে না তখন আমি এটিই ডিপ্লয় করি।

১৬. কখন RAC ব্যবহার করবেন না

RAC শক্তিশালী, তবে সবসময় সঠিক উত্তর নয়:

• একক-অ্যাপ workload যেগুলোর HA দরকার নেই — অতিরিক্ত
• সীমিত বাজেট — RAC-তে shared storage, বেশি লাইসেন্স, জটিল সেটআপ দরকার
• দক্ষ DBA ছাড়া — RAC নিরাপদে চালাতে দক্ষতা লাগে
• শুধু DR-এর জন্য — বদলে Data Guard ব্যবহার করুন

সবচেয়ে উপযুক্ত: mission-critical OLTP সিস্টেম যেখানে প্রতি মিনিট ডাউনটাইমে বড় অঙ্কের খরচ হয় — ব্যাংক, টেলকো, এয়ারলাইন, ERP backend।

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

Oracle RAC ও Data Guard-এর মধ্যে পার্থক্য কী?

RAC একটি একক সাইটের ভেতরে একটিমাত্র shared ডেটাবেজের বিপরীতে একাধিক সক্রিয় instance চালায় — server ব্যর্থতা থেকে রক্ষা করে প্রায়-তাৎক্ষণিক failover দিয়ে। Data Guard অন্য একটি স্থানে ডেটাবেজের আলাদা physical কপি রক্ষণাবেক্ষণ করে — সাইট হারানো, storage corruption ও দুর্যোগ থেকে রক্ষা করে। এরা একে অপরের পরিপূরক, প্রতিদ্বন্দ্বী নয় — গুরুত্বপূর্ণ সিস্টেমগুলো দুটিই চালায়।

Oracle RAC কি মাত্র ২টি node-এ চলতে পারে?

হ্যাঁ — ২ node-ই সবচেয়ে প্রচলিত প্রোডাকশন কনফিগারেশন, এবং এটি পূর্ণ উচ্চ availability দেয়। সতর্কতা হলো capacity: একটি node ব্যর্থ হলে টিকে থাকা node-টিকে সম্পূর্ণ workload বহন করতে হয়, তাই প্রতিটি node-কে peak load-এর ১০০%-এর জন্য size করুন। N+1 headroom চাইলে ৩ node-এ যান।

Oracle RAC-এ split-brain কী?

Split-brain হলো সেই পরিস্থিতি যেখানে node গুলো পরস্পরের সঙ্গে যোগাযোগ হারায় কিন্তু দুটোই স্বাধীনভাবে shared ডেটাবেজে লিখতে থাকে — যা ডেটাবেজকে corrupt করে ফেলত। RAC এটি ঠেকায় voting disk দিয়ে: যে node অধিকাংশ voting disk বা টিকে থাকা cohort-এ পৌঁছাতে পারে না, তাকে জোর করে evict (reboot) করা হয়। Eviction নিষ্ঠুর দেখালেও এটি আসলে cluster-এর আপনার ডেটা রক্ষা করা।

Oracle RAC-এর কি shared storage দরকার?

হ্যাঁ, অবশ্যই। প্রতিটি RAC node-কে একই disk দেখতে হবে — সাধারণত সব node-এ present করা SAN LUN, যা ASM পরিচালনা করে। Shared storage ছাড়া RAC নেই; এটি দিতে না পারলে আপনার দরকার Data Guard আর্কিটেকচার, যা ডিজাইন অনুযায়ীই প্রতি সাইটে আলাদা storage রাখে।

ছোট workload-এর জন্য কি RAC সার্থক?

সাধারণত না। RAC লাইসেন্স খরচ, shared storage-এর প্রয়োজনীয়তা এবং প্রকৃত অপারেশনাল জটিলতা যোগ করে, যা ছোট workload খুব কমই justify করে। একটি single instance আর Data Guard standby অনেক কম টাকা ও দক্ষতার বিনিময়ে চমৎকার সুরক্ষা দেয়। RAC তার খরচ পোষায় তখনই, যখন ডাউনটাইম মাপা হয় প্রতি মিনিটে টাকায়।

Oracle RAC-এ Cache Fusion কী?

Cache Fusion হলো সেই ব্যবস্থা যা সব instance-কে সামঞ্জস্যপূর্ণ রাখে: এক instance-এর যখন এমন একটি data block দরকার হয় যা অন্য instance মেমরিতে ধরে রেখেছে, তখন block-টি disk-এ লিখে আবার পড়ার বদলে সরাসরি private interconnect দিয়ে পাঠিয়ে দেওয়া হয়। এ কারণেই interconnect latency-ই RAC পারফরম্যান্সে সবচেয়ে বড় নিয়ামক।

RAC node কেন evict হয়?

তিনটি চিরাচরিত কারণ: interconnect সমস্যা (network heartbeat মিস হওয়া), storage সমস্যা (কোনো node-এর অধিকাংশ voting disk-এ অ্যাক্সেস হারানো), এবং তীব্র resource starvation — যেখানে clusterware process সময়মতো CPU পায় না। ডায়াগনোসিস শুরু করুন evict হওয়া node-এর ocssd লগে — ঠিক কোন heartbeat মিস হয়েছে তা সেখানেই লেখা থাকে।

শেষ কথা

Oracle 19c RAC হলো এন্টারপ্রাইজ-গ্রেড workload-এর জন্য এন্টারপ্রাইজ-গ্রেড সফটওয়্যার। জটিলতা বাস্তব — কিন্তু ফলটাও তেমনই। সঠিকভাবে আর্কিটেক্ট করা, ভালোভাবে পর্যবেক্ষণ করা একটি RAC cluster বছরের পর বছর নিরবচ্ছিন্ন সেবা দেয়। ভুলগুলো তখনই ঘটে যখন টিম RAC-কে "শুধু দুটি ডেটাবেজ" ভাবে — এটি তা নয়। এটি নিজস্ব আচরণ, ব্যর্থতার ধরন ও রিকভারি প্যাটার্নসহ একটি একক distributed সিস্টেম।

আপনার প্রতিষ্ঠান যদি RAC ডিপ্লয়মেন্ট, migration পরিকল্পনা করে, কিংবা বিদ্যমান cluster নিয়ে সমস্যায় থাকে, আসুন কথা বলি। আমি একাধিক শিল্পে — ব্যাংকিং, ফার্মা, সফটওয়্যার, ম্যানুফ্যাকচারিং — প্রোডাকশন RAC cluster আর্কিটেক্ট ও পরিচালনা করেছি, আর RAC-এর যে বিরল সমন্বয় দরকার — ব্যবহারিক অভিজ্ঞতার ক্ষত আর আর্কিটেকচারাল স্পষ্টতা — তা নিয়ে আসি।

সম্পর্কিত লেখা