Oracle ASM (Automatic Storage Management): Disk Group, Rebalance ও সেরা চর্চা

অনেক Oracle পারফরম্যান্স ও অ্যাভেইলেবিলিটি সমস্যার নীরব জন্ম হয় স্টোরেজেই - খণ্ডিত (fragmented) ফাইল, disk জুড়ে অসম I/O, downtime দাবি করা যন্ত্রণাদায়ক স্টোরেজ মাইগ্রেশন। Oracle ASM (Automatic Storage Management)-এর অস্তিত্বই এসব সমস্যা মিটিয়ে দেওয়ার জন্য - এটি ডেটাবেজ ফাইলের জন্য বিশেষভাবে তৈরি Oracle-এর নিজস্ব volume manager ও file system হিসেবে কাজ করে। আপনি RAC চালালে এর ওপর ইতিমধ্যেই নির্ভরশীল, আর single instance-এও এটিই স্টোরেজ সাজানোর জন্য Oracle-এর সুপারিশকৃত পথ। এই গাইডে ব্যাখ্যা করছি ASM আসলে কী, disk group ও redundancy কীভাবে কাজ করে, rebalance দিয়ে কীভাবে online স্টোরেজ যোগ ও বাদ দিতে হয়, এবং প্রোডাকশনে কীভাবে মনিটর ও ট্রাবলশুট করতে হয়।

১. ASM আসলে কী

Automatic Storage Management হলো একটি হালকা volume manager ও file system যা Oracle বিশেষভাবে ডেটাবেজ ফাইলের জন্য দেয় - datafile, control file, redo log, archive log এবং RMAN backup। প্রচলিত file system-এ ফাইল রেখে কোন disk-এ কী থাকবে তা নিয়ে চিন্তা করার বদলে, আপনি ASM-কে একগুচ্ছ raw disk দেন আর সে-ই লেআউট সামলায়।

ডেটাবেজের জন্য সাধারণ file system যা ভালোভাবে করে না, ASM এমন তিনটি কাজ করে। এটি প্রতিটি ফাইলকে একটি group-এর সব disk জুড়ে সমানভাবে stripe করে, ফলে I/O স্বয়ংক্রিয়ভাবে ভারসাম্যপূর্ণ থাকে। redundancy-র জন্য এটি disk জুড়ে ডেটা mirror করতে পারে। আর স্টোরেজ যোগ বা বাদ দিলে এটি online rebalance করে, কোনো downtime ছাড়াই ডেটা সরিয়ে। ভারী ডেটাবেজ write কার্যক্রমে সাধারণ file system-কে যে fragmentation পীড়া দেয়, তা-ও এটি এড়ায়।

২. file system-এর বদলে কেন ASM ব্যবহার করবেন?

সৎ উত্তর হলো ভারসাম্য, সরলতা ও online পরিবর্তন। file system-এ একজন DBA-কে ঠিক করতে হয় কোন datafile কোন mount point-এ যাবে আর আশা করতে হয় I/O সমানভাবে ভাগ হবে - যা কদাচিৎ হয়, আর hot ফাইল hot disk তৈরি করে। ASM প্রতিটি ফাইলকে প্রতিটি disk জুড়ে স্বয়ংক্রিয়ভাবে ছড়িয়ে দেয়, ফলে লোড নকশাগতভাবেই সমান।

দ্বিতীয় কারণ হলো online স্টোরেজ অপারেশন। আরও স্পেস দরকার? disk যোগ করুন, ASM লাইভ rebalance করবে। পুরনো SAN অবসরে পাঠাচ্ছেন? নতুন disk যোগ করুন, পুরনোগুলো বাদ দিন, database খোলা অবস্থাতেই ASM ডেটা মাইগ্রেট করবে। file system-এ এটি করা মানে সাধারণত downtime। RAC-এর জন্য ASM কার্যত অপরিহার্য, কারণ এটিই সেই shared storage দেয় যা সব node একইভাবে দেখে।

৩. Disk Group, Redundancy ও Failure Group

কেন্দ্রীয় ধারণাটি হলো disk group - একগুচ্ছ disk যাকে ASM একটি একক pool হিসেবে পরিচালনা করে। বেশিরভাগ সাইট অন্তত দুটি চালায়: একটি ডেটার জন্য (প্রায়ই DATA নামে) আর একটি Fast Recovery Area (FRA)-র জন্য। তৈরির সময় প্রতিটি disk group-এর একটি redundancy level বেছে নেওয়া হয়:

• External redundancy: ASM কোনো mirroring করে না; আপনি স্টোরেজ array-র নিজস্ব RAID-এর ওপর নির্ভর করেন। SAN-এ আস্থা থাকলে সরল ও স্পেস-সাশ্রয়ী।
• Normal redundancy: ASM প্রতিটি extent-এর দুটি কপি রাখে, failure group জুড়ে mirror করা - একটি failure group হারালেও টিকে থাকে।
• High redundancy: তিনটি কপি - দুটি failure group হারালেও টিকে থাকে। যেখানে স্টোরেজ নিজে অন্যভাবে সুরক্ষিত নয় সেখানে ব্যবহৃত হয়।

একটি failure group দিয়ে আপনি ASM-কে জানান কোন disk-গুলো একটি ঝুঁকি ভাগ করে - যেমন একটি স্টোরেজ enclosure বা একটি controller-এর সব disk। normal বা high redundancy-তে ASM নিশ্চিত করে mirror কপিগুলো ভিন্ন failure group-এ পড়ে, ফলে পুরো একটি enclosure ব্যর্থ হলেও ডেটা হারায় না।

৪. Disk Group তৈরি ও ব্যবস্থাপনা

আপনি asmca GUI দিয়ে ASM পরিচালনা করতে পারেন, তবে SQL ও command-line পথই আপনি script ও automate করেন। disk group DDL চলে একটি ASM instance সংযোগ থেকে (sqlplus / as sysasm)।

-- Create a normal-redundancy disk group with two failure groups
CREATE DISKGROUP data NORMAL REDUNDANCY
  FAILGROUP fg1 DISK '/dev/sdb1' NAME data_0001
  FAILGROUP fg2 DISK '/dev/sdc1' NAME data_0002
  ATTRIBUTE 'au_size' = '4M',
            'compatible.asm' = '19.0.0.0.0',
            'compatible.rdbms' = '19.0.0.0.0';

allocation unit (au_size) হলো striping-এর granularity; বড় ডেটাবেজের জন্য 4M একটি প্রচলিত পছন্দ। একবার তৈরি হলে database কেবল disk group নাম দিয়ে ফাইল রেফার করে, যেমন +DATA, আর physical placement ASM সামলায়।

৫. Disk যোগ ও বাদ দেওয়া: Online Rebalance

দৈনন্দিন অপারেশনে এটিই ASM-এর সেরা ফিচার। স্টোরেজ পরিবর্তন ঘটে database খোলা অবস্থায়।

-- Add a new disk - ASM automatically starts a rebalance
ALTER DISKGROUP data ADD DISK '/dev/sdd1' NAME data_0003;

-- Retire an old disk - data migrates off it, then it drops
ALTER DISKGROUP data DROP DISK data_0001;

-- Control how aggressively the rebalance runs (0 = pause, 1 = gentle, up to high)
ALTER DISKGROUP data REBALANCE POWER 4;

-- Watch rebalance progress
SELECT operation, state, power, sofar, est_work, est_minutes
FROM   v$asm_operation;

REBALANCE POWER সেটিংটিই ব্যবহারিক লিভার। বেশি power দ্রুত শেষ করে কিন্তু বেশি I/O খরচ করে, তাই অফিস সময়ে এটি মাঝারি রাখেন আর নিরিবিলি সময়ে বাড়ান। বাদ দেওয়া disk তার rebalance শেষ না হওয়া এবং V$ASM_DISK-এ তা চলে যাওয়া না দেখানো পর্যন্ত physically সরানো হয় না - আগেভাগে টেনে বের করলে normal redundancy-তে ডেটা হারানোর ঝুঁকি থাকে।

৬. দৈনন্দিন ASM মনিটরিং

দুটি টুলসেট প্রায় সবকিছু সামলায়: asmcmd command line এবং V$ASM view-গুলো।

-- asmcmd: quick space and file checks (as the grid user)
asmcmd lsdg              # disk groups with free/used space
asmcmd lsdsk -k          # disks and their sizes
asmcmd du +DATA/ORCL     # space used by a database's files

-- SQL: free space and disk health
SELECT name, type, total_mb, free_mb,
       ROUND(free_mb/total_mb*100,1) AS pct_free
FROM   v$asm_diskgroup;

SELECT group_number, name, path, mount_status, mode_status, state
FROM   v$asm_disk ORDER BY group_number;

যে একটি সংখ্যা নিয়ে alert দেওয়া উচিত তা হলো প্রতি disk group-এর free space। normal বা high redundancy-তে আপনাকে একটি disk ব্যর্থতা সামলানোর মতো যথেষ্ট free space-ও রাখতে হবে - হারানো ডেটা পুনরায় mirror করতে যে স্পেস লাগে - যা ASM required mirror free space হিসেবে রিপোর্ট করে। একটি mirrored disk group অতিরিক্ত পূর্ণ চালালে তার নিজে-সারানোর সক্ষমতা হারায়।

৭. RAC-এ ASM এবং Flex ASM

একটি RAC ক্লাস্টারে ASM চলে Grid Infrastructure-এর অংশ হিসেবে এবং সেই shared storage দেয় যা প্রতিটি node দেখে। ঐতিহাসিকভাবে প্রতিটি node নিজের ASM instance চালাত, আর সেই instance মারা গেলে সেই node-এর database instance-ও তার সঙ্গে নেমে যেত।

Flex ASM সেই আঁটসাঁট সংযুক্তি দূর করেছে। database instance-গুলো network-এর মাধ্যমে ASM-এ সংযোগ দেয়, আর একটি নির্দিষ্ট সংখ্যক ASM instance পুরো ক্লাস্টারকে সেবা দেয়। কোনো node-এর ASM instance ব্যর্থ হলে তার database-গুলো কেবল অন্য node-এর একটি ASM instance-এ পুনরায় সংযুক্ত হয়ে চলতে থাকে। এতে স্টোরেজ স্তর অনেক বেশি স্থিতিস্থাপক হয়, আর এটিই RAC-এর আধুনিক ডিফল্ট কনফিগারেশন।

৮. সাধারণ সমস্যা ও যেভাবে সামলাবেন

• disk group ভরে যাওয়া: সবচেয়ে ঘন ঘন আসা ASM alert। disk যোগ করুন (online rebalance) বা FRA-তে স্পেস পুনরুদ্ধার করুন। একটি mirrored group এত পূর্ণ চালাবেন না যে তা তার rebalance headroom হারায়।
• rebalance বেশি সময় নিচ্ছে বা পারফরম্যান্সে আঘাত করছে: অফিস সময়ে REBALANCE POWER কমান, রাতে বাড়ান। এটি পুরোপুরি online ও resumable।
• ORA-15041 (diskgroup space exhausted) / ORA-15040: স্পেস বা একটি অনুপস্থিত disk। অপ্রত্যাশিত অবস্থায় থাকা কোনো disk-এর জন্য V$ASM_DISK দেখুন এবং নিশ্চিত করুন OS আসলেই সব disk উপস্থাপন করছে।
• disk খুঁজে পাওয়া যায়নি: ASM কেবল সেসব disk দেখে যা তার discovery string-এর সঙ্গে মেলে ও সঠিক OS permission আছে। grid user-এর জন্য device permission এবং asm_diskstring প্যারামিটার যাচাই করুন।

৯. একটি বাস্তব মাইগ্রেশন: Zero Downtime-এ SAN বদল

একটি ফার্মা ক্লায়েন্টকে একটি প্রোডাকশন database একটি পুরনো স্টোরেজ array থেকে একটি নতুনটিতে সরাতে হয়েছিল, আর validated সিস্টেমটি কোনো আউটেজ নিতে পারত না। file system-এ এর মানে হতো একটি maintenance window আর একটি ঝুঁকিপূর্ণ কপি।

আমরা যা করেছিলাম: নতুন array-র LUN-গুলো সার্ভারে উপস্থাপন করলাম, সেগুলো DATA ও FRA disk group-এ যোগ করলাম, এবং ASM-কে দিনে মাঝারি REBALANCE POWER আর রাতে বেশি power-এ নতুন disk-গুলোতে ডেটা rebalance করতে দিলাম। নতুন disk পুরোপুরি ভরে গেলে পুরনোগুলো বাদ দিলাম - ASM শেষ extent-গুলো online তা থেকে মাইগ্রেট করল - আর V$ASM_OPERATION rebalance সম্পন্ন দেখানোর পরই সেগুলো সরানো হলো। database কখনও বন্ধ হয়নি, অ্যাপ্লিকেশন ব্যবহারকারীরা কিছু টের পাননি, আর validation রেকর্ডে একটি পরিষ্কার, নিয়ন্ত্রিত পরিবর্তন দেখা গেল। এটি স্বাভাবিকভাবেই একটি নিয়মিত health check এবং যৌক্তিক performance tuning-এর সঙ্গে জোড় বাঁধে, কারণ ভারসাম্যপূর্ণ স্টোরেজ একটি গোটা শ্রেণির I/O bottleneck দূর করে।

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

Oracle ASM কী এবং কেন ব্যবহার করবেন?

ASM (Automatic Storage Management) হলো ডেটাবেজ ফাইলের জন্য Oracle-এর নিজস্ব volume manager ও file system। এটি একটি disk group-এর সব disk জুড়ে ডেটা স্বয়ংক্রিয়ভাবে stripe করে ভারসাম্যপূর্ণ I/O দেয়, redundancy-র জন্য mirror করতে পারে এবং স্টোরেজ বদলালে online rebalance করে। এটি ম্যানুয়াল ফাইল বসানো দূর করে, এটিই সুপারিশকৃত স্টোরেজ লেআউট এবং RAC-এর জন্য কার্যত অপরিহার্য।

disk group কী এবং কোন redundancy বেছে নেব?

disk group হলো একগুচ্ছ disk যা ASM একটি ইউনিট হিসেবে পরিচালনা করে। External redundancy কোনো ASM mirroring করে না, array-র RAID-এর ওপর নির্ভর করে; normal redundancy failure group জুড়ে দুটি mirror কপি রাখে; high redundancy তিনটি রাখে। SAN-এর সুরক্ষায় আস্থা থাকলে external বেছে নিন, আর disk বা enclosure হারানোর বিরুদ্ধে ASM নিজেই রক্ষা করুক চাইলে normal বা high নিন।

downtime ছাড়া কি স্টোরেজ যোগ বা বাদ দেওয়া যায়?

হ্যাঁ - এটি ASM-এর সবচেয়ে বড় শক্তিগুলোর একটি। disk যোগ করলে একটি online rebalance শুরু হয় যা তাতে ডেটা ছড়িয়ে দেয়, আর disk বাদ দিলে আগে তা থেকে ডেটা সরিয়ে নেয় - পুরোটাই database খোলা অবস্থায়। REBALANCE POWER নিয়ন্ত্রণ করে অপারেশনটি কত দ্রুত চলবে বনাম কতটা I/O খরচ করবে।

REBALANCE POWER কী করে?

এটি ঠিক করে rebalance-এর সময় ASM কতটা আক্রমণাত্মকভাবে ডেটা সরাবে। বেশি power দ্রুত শেষ করে কিন্তু বেশি I/O ব্যবহার করে ও পারফরম্যান্সে প্রভাব ফেলতে পারে; কম power মৃদু কিন্তু ধীর। প্রচলিত চর্চা হলো অফিস সময়ে মাঝারি power আর রাতে বেশি। rebalance online এবং resumable।

RAC ক্লাস্টারে Flex ASM কী?

Flex ASM database instance-গুলোকে একই node-এর একটি local ASM instance-এর ওপর নির্ভর না করে network-এর মাধ্যমে ASM-এ সংযোগ দিতে দেয়। কোনো node-এর ASM instance ব্যর্থ হলে তার database-গুলো অন্য node-এর একটি ASM instance-এ পুনরায় সংযুক্ত হয়ে চলতে থাকে, ফলে স্টোরেজ স্তর অনেক বেশি স্থিতিস্থাপক হয়। এটি আধুনিক RAC-এর ডিফল্ট কনফিগারেশন।