Artarad_oracle12c

آشنایی با مفهوم LeafNode در Oracle Flex Cluster 12c

آشنایی با مفهوم LeafNode در Oracle Flex Cluster 12c

در پایگاه داده اوراکل نسخه ۱۲c با معرفی flex clusters که از فناوری Hub & Spoke استفاده می‌شود امکاناتی فراتر از ساختار cluster ها در نسخه های پیشین به شرح ذیل فراهم می آورد:

  • مصرف کمتر منابع شبکه در ارتباطات بین Node هادر مقایسه با نسخه های پیشین
  • استفاده کمتر منابع کلیدی سرویس clusterware مانند OCR و Voting Disk

 

در ساختار flex cluster از دو نوع Node استفاده می شود:

  • Hub Node
  • Leaf Node

Hub Nodes

  • این نوع Node ها مشابه Node های مرسوم در نسخه های پیش از ۱۲c است و هسته اصلی cluster را تشکیل می دهند.
  • هر Hub Node از طریق شبکه Private به روش Peer-to-Peer  به دیگر Hub Node ها متصل می شود.
  • هر Hub Node به Shared Storage و به طبع آن OCR و Voting Disk های موجود دسترسی دارد.
  • یک Hub Node امکان میزبانی از یک ASM Instance و DB Instance و Application را دارد.
  • هر cluster باید حداقل یک و حداکثر ۶۴ Hub Node را دارا باشد.

 

Leaf Nodes

  • این نوع Node ها به نسبت Hub Node ها از تنیدگی کمتری با cluster برخوردار هستند و به طور مستقیم با هم ارتباطی ندارند.
  • هر Leaf Node از طریق یک Hub Node به cluster متصل می‌شود و درخواست اطلاعات می نماید.
  • با توجه به عدم نیاز دسترسی مستقیم Leaf Node ها به Shared Storage می‌توان به منظور امکان اعمال تغییر وضعیت آن‌ها به Hub Node در آینده این امکان را پیش‌بینی نمود.
  • نسخه سبکی ار clusterware در Leaf Node مورد استفاده قرار می‌گیرد.
  • امکان میزبانی DB Instance و ASM Instance برای Leaf Node وجود ندارد.
  • امکان میزبانی انواع مختلفی از Application ها از قبیل Fusion Middleware و EBS و IDM برای Leaf Node وجود دارد. همچنین در صورت از مدار خارج شدن Leaf Node امکان جابجایی Application به Leaf Node‌دیگر وجود دارد.
  • flex cluster می‌تواند هیچ Leaf Node نداشته باشد.
  • همه Leaf Node ها بر روی شبکه Public و Private مشابه Hub Node ها مستقر هستند.

 

Hub Node ها امکان فعالیت در ساختار flex cluster بدون وجود هیچ Leaf Node را دارند ولی برای وجود Leaf Node در ساختار flex cluster وجود حداقل یک Hub Node الزامی است. با فعالیت clusterware بر روی یک Leaf Node، گِره مذکور با استفاده از GNS نسبت به شناخت Hub Node ها و اتصال به cluster از طریق یکی از آن‌ها اقدام می کند. یک Hub Node ممکن است با صفر یا تعداد بیشتر از Leaf Node متصل باشد. به صورت دوره ای از طریق ارسال پیام Heartbeat از جانب Hub Node به سمت Leaf Node ها از صحت ارتباطات cluster اطمینان حاصل می شود.

یک Standard cluster می‌تواند به یک flex cluster تغییر وضعیت دهد، ولی تغییر وضعیت flex cluster به Standard clusters بدون تغییر تنظیمات cluster میسر نیست.

پس از حذف یک Hub Node از ساختار cluster چه اتفاقی خواهد افتاد؟

یک Hub Node به دلایل زیر می‌تواند از ساختار cluster جدا شود:

  • از مدار خارج شدن گِره
  • خاموش شدن سرور
  • توقف سرویس clusterware

 

در این وضعیت Leaf Node مرتبط با Hub Node از مدار خارج شده به گِره فعال دیگر در cluster متصل خواهد شد.

در مطلب حاضر موارد ذیل مورد ارزیابی قرار می گیرد:

  • شناسایی Hub Node که Leaf Node به آن متصل است.
  • از مدار خارج شدن Hub Node و انتقال Leaf Node به گِره دیگر

 

شرح اقدامات

به منظور اجرای موارد فوق یک flex cluster نسخه ۱۲c با Node های ذیل موجود است:

 

  • Hub Nodes:

Host01

Host02

Host03

  • Leaf Nodes:

Host04

Host05

 

اجرای عملیات

در مرحله نخست از فعالیت Hub Node host01 و Leaf Node host04 اطمینان حاصل می کنیم.

 

[root@host01 log]# crsctl get node role status -all

Node ‘host01’ active role is ‘hub’

Node ‘host04’ active role is ‘leaf’

 

از آنجاییکه Host01 تنها Hub Node فعال در cluster است در نتیجه Leaf Node Host04 به آن متصل است. این موضوع با بررسی trace فایل پروسس ocssdrim قابل رؤیت می باشد:

 

[root@host04 trace]#export ORACLE_BASE=/u01/app/grid

[root@host04 ~]# cat  $ORACLE_BASE/diag/crs/host04/crs/trace/ocssdrim.trc |grep ‘Sending a ping msg to’ | tail -1

۲۰۱۶-۰۵-۰۴ ۱۰:۵۰:۱۵٫۳۱۵۱۳۸ :    CSSD:1085761856: clssbnmc_PeriodicPing_CB: <span style=”color: red;”><strong>Sending a ping msg to host host01</strong></span>, number 1, using handle (0x137e5d0) last msg to hub at 4294684730, connection timeout at 4294714730, current time 4294686330

اکنون Hub Node host02 و Leaf Node host05  را به cluster اضافه می نماییم:

 

[root@host01 log]# crsctl get node role status -all

Node ‘host01’ active role is ‘hub’

Node ‘host02’ active role is ‘hub’

Node ‘host04’ active role is ‘leaf’

Node ‘host05’ active role is ‘leaf’

به منظور شناسایی Hub Node مرتبط با Leaf Node Host05 نگاهی به trace فایل پروسس ocssdrim در Host05 می اندازیم:

[root@host05 trace]#export ORACLE_BASE=/u01/app/grid

[root@host05 ~]# cat  $ORACLE_BASE/diag/crs/host05/crs/trace/ocssdrim.trc |grep ‘Sending a ping msg to’ | tail -1

۲۰۱۶-۰۵-۰۴ ۱۱:۱۲:۰۱٫۰۰۸۲۸۳ :    CSSD:1086187840: clssbnmc_PeriodicPing_CB: <span style=”color: red;”><strong>Sending a ping msg to host host01</strong></span>, number 1, using handle (0x14055d0) last msg to hub at 4294948750, connection timeout at 11454, current time 4294951260]]

 

مشاهده می‌شود که Leaf Node Host05 به Hub Node Host01 متصل است.

اکنون سرویس clusterware در Host01 متوقف شده و وضعیت انتقال هر دو Leaf Node به دیگر Hub Node موجود بررسی می شود:

 

[root@host01 log]# crsctl stop crs

[root@host02 ~]# crsctl get node role status -all

Node ‘host02’ active role is ‘hub’

Node ‘host04’ active role is ‘leaf’

Node ‘host05’ active role is ‘leaf’

 

بررسی صحت انتقال Host04 به Host02:

 

[root@host04 ~]# cat  $ORACLE_BASE/diag/crs/host04/crs/trace/ocssdrim.trc |grep ‘Destroying connection’ | tail -1

۲۰۱۶-۰۵-۰۴ ۱۱:۱۷:۳۱٫۹۳۲۷۷۰ :    CSSD:1085761856: clssbnmConnDestroy: <span style=”color: red;”><strong>Destroying connection object (0x1061200) for host host01</strong></span>

 [root@host04 ~]# cat  $ORACLE_BASE/diag/crs/host04/crs/trace/ocssdrim.trc |grep ‘Sending a ping msg to’ | tail -1

۲۰۱۶-۰۵-۰۴ ۱۱:۱۸:۲۱٫۸۶۰۷۷۱ :    CSSD:1085761856: clssbnmc_PeriodicPing_CB: <span style=”color: red;”><strong>Sending a ping msg to host host02</strong></span>, number 2, using handle (0x17e2fe0) last msg to hub at 1404044, connection timeout at 1434044, current time 1405324

همچنین بررسی صحت انتقال Host05 به Host02:

 

[root@host05 ~]# cat $ORACLE_BASE/diag/crs/host05/crs/trace/ocssdrim.trc |grep ‘Destroying connection’ | tail -1

[root@host05 ~]# cat  $ORACLE_BASE/diag/crs/host05/crs/trace/ocssdrim.trc |grep ‘Destroying connection’ | tail -1

۲۰۱۶-۰۵-۰۴ ۱۱:۱۷:۳۱٫۸۷۳۹۹۳ :    CSSD:1086187840: clssbnmConnDestroy: <span style=”color: red;”><strong>Destroying connection object (0x16979f0) for host host01</strong></span>

 [root@host05 ~]# cat  $ORACLE_BASE/diag/crs/host05/crs/trace/ocssdrim.trc |grep ‘Sending a ping msg to’ | tail -1

۲۰۱۶-۰۵-۰۴ ۱۱:۱۷:۳۶٫۷۵۱۶۲۸ :    CSSD:1086187840: clssbnmc_PeriodicPing_CB: <span style=”color: red;”><strong>Sending a ping msg to host host02</strong></span>, number 2, using handle (0x10950b0) last msg to hub at 318184, connection timeout at 348184, current time 319664

 

جمع بندی

 

  • ساختار flex clusters در نسخه ۱۲c معرفی شده و شامل ۲ نوع گِره می شود: Leaf Node و Hub Node
  • از آنجایی که هر Hub Node به طور مستقیم با Shared Storage در ارتباط است، گِره های Leaf Node ها نیازی به ارتباط مستقیم با Shared Storage نداشته و از طریق Hub Node به clusters متصل می شوند.
  • در هنگام آغاز فعالیت سرویس clusterware بر روی Leaf Node، گِره مربوطه به طور خودکار با استفاده از GNS به منظور شناسایی و اتصال به cluster از طریق Hub Node های موجود اقدام می کند.
  • در صورت از مدار خارج شدن یک Hub Node، دیگر Leaf Node های مرتبط با آن به Hub Node فعال دیگری در cluster متصل خواهد شد.

 

0 پاسخ

دیدگاه خود را ثبت کنید

تمایل دارید در گفتگوها شرکت کنید؟
در گفتگو ها شرکت کنید.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *