একটি Oracle Real Application Clusters (RAC) এনভায়রনমেন্টে, সকল ইন্সট্যান্স বা সার্ভার হাই-স্পিড ইন্টারকনেক্ট ব্যবহার করে প্রাইভেট নেটওয়ার্কে একে অপর সাথে কমিউনিকেট করে। যদি RAC-এ ইন্সট্যান্স মেম্বাররা এই প্রাইভেট ইন্টারকনেক্টের মাধ্যমে একে অপরকে পিং বা কানেক্ট করতে ব্যর্থ হয়, তবে ফিজিক্যালি আপ এবং রানিং সকল সার্ভার (এবং সেসে সার্ভারগুলোতে ডাটাবেস ইন্সট্যান্স) একটি কন্ডিশনে পড়ে যেতে পারে যাকে split-brain বলা হয়।
একটি Oracle ক্লাস্টারে (Oracle RAC 12c Release 2 ভার্সনের পূর্বে), যখন স্প্লিট-ব্রেন সমস্যা নেটওয়ার্ক বা ডিস্ক ইস্যুতে হয়, তখন লোয়েস্ট নোড-নাম্বার 가진 নোডটি ক্লাস্টারে সারভাইভ করত। যাইহোক, লেটেস্ট Oracle RAC 12c Release 2-এ, স্প্লিট-ব্রেনের কারণে সাব-ক্লাস্টারে সমান সংখ্যক নোড তৈরি হলে ক্যান্ডিডেট নোড যাদের ইভিক্ট করা হবে সেগুলো নির্বাচন করার অ্যালগরিদমে পরিবর্তন আনা হয়েছে।
এই ব্লগ পোস্টে Oracle RAC 12c Release 2-এ নোড-ওয়েটিং ফিচারভিত্তিক নোড ইভিকশন অ্যালগরिदমের পরিবর্তনগুলো কভার করা হয়েছে।
নোড-ওয়েটিং অ্যালগরিদমের পরিচিতি
নিচের ছবিতে নোড-ওয়েটিং অ্যালগরিদম চিত্রিত:
Node Weighting in Oracle
Source: https://goo.gl/images/qarxrq
Node Weighting হল Oracle RAC 12c Release 2-এ চালু করা একটি নতুন ফিচার যা ফেন্সিংয়ের সময় ক্লাস্টারে হোস্ট করা ওয়ার্কলোড বিবেচনা করে। যখন একটি split-brain পরিস্থিতি ঘটে, Oracle Clusterware নির্দিষ্ট নিয়ম প্রয়োগ করে সারভাইভিং কোহর্ট নির্বাচন করতে, এবং সিস্টেম এমন একটি নোড ইভিক্ট করতে পারে যা ক্রিটিক্যাল রিসোর্সের সাথে রান করছে। এই নতুন ফিচার ব্যবহার করে, আমরা নির্দিষ্ট নোডে ওয়েট অ্যাসাইন করতে পারি এবং ক্লাস্টার থেকে টার্মিনেট হওয়া থেকে সেটি বাঁচাতে পারি।
একটি নতুন তৈরি ট্যাগ, CSS_CRITICAL, বিভিন্ন লেভেল বা কম্পোনেন্টে সেট করা যায় সেগুলো "critical" হিসেবে মার্ক করতে যাতে ফেইলার সময় ক্লাস্টার সেগুলো প্রিজার্ভ করার চেষ্টা করে। যখন Oracle Clusterware স্প্লিট ব্রেনের কেসে কোন নোড ইভিক্ট করা হবে সেটি নির্ণয় করে, CSS_CRITICAL ট্যাগ 명예 করা হয় যতক্ষণ না অন্য কোনো টেকনিক্যাল কারণ নোডের সারভাইভালকে প্রতিবন্ধক করে (যেখানে ফেইলারের সময় নোডে কমপক্ষে একটি ক্রিটিক্যাল কম্পোনেন্ট থাকে)। কনসেপ্টটি позволяет إذا সব কিছু সমান থাকে তবে অধিকাংশ কাজ অপ্রভাবিত থাকে।
নোড-ওয়েটিং অ্যালগরিদম টাস্ক
নোড-ওয়েটিং অ্যালগরিদম নিচের টাস্কগুলো পারফর্ম করে:
- ডাটাবেস ইন্সট্যান্স বা সার্ভিসে ওয়েট অ্যাসাইন করে। আমরা srvctl add database বা srvctl add service কমান্ডের সাথে
-css_criticalকেyesসেট করতে পারি ডাটাবেস ইন্সট্যান্স বা সার্ভিস যোগ করার সময়। আমরা srvctl modify database এবং srvctl modify service কমান্ড দিয়ে প্যারামিটার সেট বা পরিবর্তন করতে পারি। - non ora.* রিসোর্সে ওয়েট অ্যাসাইন করে। আমরা
-attr CSS_CRITICAL=yesপ্যারামিটার *crsctl add resource* এবং *crsctl modify resource* কমান্ডের সাথে ব্যবহার করি রিসোর্স যোগ বা মডিফাই করার সময়। - একটি সার্ভারে ওয়েট অ্যাসাইন করে। আমরা crsctl set server কমান্ডের সাথে
-css_criticalপ্যারামিটারyes-এ সেট করি।
ডাটাবেস ইন্সট্যান্স বা সার্ভিসে ওয়েট অ্যাসাইন করার কিছু উদাহরণ:
$srvctl modify database –d css_critical yes
$srvctl modify service –db -service css_critical yes
যদি রিসোর্সে ওয়েট অ্যাসাইন না করা থাকে, তবে অ্যালগরিদম নিচের বিবেচনাগুলো পরীক্ষা করে:
- কোন নোডে সর্বোচ্চ সংখ্যক সার্ভিস তৈরি করা আছে?
- ইনস্ট্যান্সের জন্য সিঙ্গলটন সার্ভিস তৈরি করা আছে কিনা?
- নোডটি কনফিগার্ড Flex ASM ইন্সট্যান্স কিনা?
- পাবলিক নেটওয়ার্ক ফেইলার হয়েছিল কিনা?
- নোডের টাইপ কী - hub নাকি leaf?
টেস্ট কেস
নিচের কোড ওয়াক-থ্রু একটি কেস পরীক্ষা করে যেখানে bond2 ব্যবহার করা হয়েছে একটি two-node ক্লাস্টারের জন্য প্রাইভেট ইন্টারকনেক্ট হিসেবে।
$oifcfg getif
bond0 147.167.80.0 global public
bond2 10.168.33.32 global cluster_interconnect
$olsnodes -s -n
node1 1 Active
node2 2 Active
$
$crsctl set server css_critical yes
$crsctl get server css_critical
CRS-5092: Current value of the server attribute CSS_CRITICAL is yes.
$
চলুন bond2 স্টপ করি node1 এবং node2-এর মধ্যে কমিউনিকেশন ফেইলার সিমুলেট করতে:
#ifdown bond2
$olsnodes -s -n
node1 1 Active
node2 2 Inactive
OCSSD.trc থেকে আউটপুট
2018-01-09 11:01:21.220 : CSSD:1825834752: clssnmrCheckNodeWeight: node(1) has weight stamp(393228187) pebbles (0) goldstars (0) flags (3) SpoolVersion (0)
2018-01-09 11:01:21.220 : CSSD:1825834752: clssnmrCheckNodeWeight: node(2) has weight stamp(0) pebbles (0) goldstars (0) flags (0) SpoolVersion (0)
2018-01-09 11:01:21.727 : CSSD:1825834752: clssnmrCheckNodeWeight: node(1) has weight stamp(393228187) pebbles (0) goldstars (0) flags (3) SpoolVersion (0)
2018-01-09 11:01:21.727 : CSSD:1825834752: clssnmrCheckNodeWeight: node(2) has weight stamp(0) pebbles (0) goldstars (0) flags (0) SpoolVersion (0)
2018-01-09 11:01:21.727 : CSSD:1825834752: clssnmrCheckNodeWeight: Server pool version not consistent
2018-01-09 11:01:21.727 : CSSD:1825834752: clssnmrCheckNodeWeight: stamp(393228187), completed(1/2)
উপসংহার
RAC 12c Release 2 থেকে, নতুন অ্যালগরিদম স্প্লিট-ব্রেন সিনেরিওর время ইভিক্ট বা রিটেইন হওয়া নোডগুলোর সিদ্ধান্ত নেয় নিচের মতে:
- যদি সাব-ক্লাস্টারের সাইজ ভিন্ন হয়, তবে ফাংশনালিটি পূর্বের রিলিজের মতোই থাকে।
- যদি সকল সাব-ক্লাস্টার একই সাইজের হয়, তবে ফাংশনালিটি নিচের মতে মডিফাইড হয়েছে:
- যদি সাব-ক্লাস্টারগুলোর নোড ওয়েট সমান হয়, তবে লোয়েস্ট নোড নাম্বার 가진 সাব-ক্লাস্টার সারভাইভ করে যাতে two-node ক্লাস্টারে লোয়েস্ট নোড নাম্বার 가진 নোড সারভাইভ করে।
- যদি সাব-ক্লাস্টারগুলোর নোড ওয়েট অসমান হয়, তবে হাইয়ার ওয়েট 가진 সাব-ক্লাস্টার সারভাইভ করে যাতে two-node ক্লাস্টারে লোয়েস্ট নোড নাম্বার 가진 নোড কম ওয়েটের কারণে ইভিক্ট হয়।
সার্ভার ওয়েট-ভিত্তিক নোড ইভিকশন ব্যবহার করে, আমরা Oracle Clusterware ফেইলার রিকভারি মেকানিজমের ওপর অধিক কন্ট্রোল পাই ক্লাস্টার নোডগুলোর মধ্যে কোনগুলো টার্মিনেট বা ইভিক্ট হবে স্প্লিট ব্রেন ইভেন্টে সিলেক্ট করে। আপনার এই টপিক নিয়ে কোনো প্রশ্ন বা গাইডেন্স প্রয়োজন হলে, নিচে কমেন্ট ফিল্ডে কমেন্ট যোগ করুন।