VMware در مقابل Oracle - ذخیره سازی - قسمت سوم

فعال یا غیرفعال کردن write protection در VMFS

همانطور که گفتیم VMFS یک فایل سیستم کلاستر شونده است. یکی از قابلیت های VMFS و هر فایل سیستم کلاستری پشتیبانی از عملیات multi-writer است. با فعالسازی این قابلیت هر دیسک مجازی VMFS می تواند به بیشتر از یک ماشین متصل باشد و همزمان توسط ماشین ها برا عملیات نوشتن و خواندن مورد استفاده قرار گیرد.

به شکل پیش فرض این قابلیت غیر فعال است. دلیل غیر فعال بودن این ویژگی به شکل پیش فرض این است که برخی از تکنولوژی های Vmware از این قابلیت پیشتیبانی نمی کنند و فعال بودن آن در سیستم عامل های زیادی به شکل پیش فرض پشتیبانی نمی شود.

لیست ویژگی های پشتیبانی شده و پشتیبانی نشده توسط این قابلیت

ویژگی پشتیبانی عدم پشتیبانی یادداشت
روشن کردن، خاموش کردن و ریستارت ماشین مجازی
Suspend VM ×
اضافه کردن hot دیسک مجازی تنها وقتی آداپتورها وجود داشته باشند
حذف کردن hot دیسک مجازی
افزایش hot سایز دیسک مجازی ×
connect و disconnect دستگاه ها
گرفتن snapshot × راهکارهای پشتیبان گیری مجازی همه از vStorage API ها استفاده می کنند. به عنوان مثال VMware Data Recovery یا vSphere Data Protection این موارد پشتیبانی نمی شوند.
گرفتن snapshotهای فوری از دیسک های مستقل پشتیبانی شده از vSphere 5.1 update2 به بعد
Clon گیری ×
Storage vMotion × دیسک های کلاستری نمی توانند با استفاده از Storage vMotion جا به جا شوند چون کل ماشین مجازی برای آغاز عملیات مهاجرت لازم است. 
Changed Block Tracking (CBT) ×
vSphere Flash Read Cache (vFRC) × نوشتن داده های موجود بر روی کش بر روی داده های قدیمی دیسک می تواند موجب خرابی یا از دست دادن داده شود
vMotion پشتیبانی فقط برای Oracle RAC صورت گرفته است و محدودیت 8 هاست را دارد

محدودیتها

  • هنگام استفاده از حالت multi-writer دیسک مجازی حتما باید در حالت eager zeroed thick باشد و نمی تون از حالت zeroed thick یا thin provisioned استفاده کرد. برای اطلاعات بیشتر به این لینک مراجعه کنید: https://kb.vmware.com/s/article/1033570
  • برای اضافه کردن hot دیسک مجازی باید فلگ رو موقتا بردارید.
  • وقتی در حال استفاده از حالت multi-writer هستید ماشین های مجازی نباید به کنترلرهای NVMe متصل باشند.
  • از vSphere 6.7 Update 1 به بعد ماشین ها با دیسک هایی با ویژگی multi-writer فعال می توانند بیشتر از 8 هاست را پشتیبانی کنند. برای فعالسازی این قابلیت شما باید ویژگی VMFS3/GBLAllowMW را فعال کنید.

VMware vSphere Virtual Volumes

نگرانی های بسیاری درباره استفاده از مجازی سازی برای سرویس پایگاه داده در بیزنس هایی با داده های چند ترابایتی وجود دارد. (مشکلات زیادی همانند تاخیرهای لایه CPU در محاسبه و یا استفاده نادقیق از منابع گزارش داده شده) از جمله موارد زیر:

  • بیزنس هایی با پایگاه داده های حساس و با حجم بالا و قابل افزایش با SLA بالا جهت حفط پرفورمنس
  • پایگاه داده ها با رشد سایز بالا که در طول زمان حجم بک آپ های آنها به سرعت افزایش پیدا می کند
  • محیط هایی که به طور منظم نیاز به گرفتن کلون و رفرش پایگاه داده از محیط عملیاتی به محیط آزمون و یا محیط توسعه دارند. حجم دیتابیس های بالا برای کلون گیری یا رفرش شدن بین محیط های مختلف نیازمند راهکارهای بهینه تر است.
  • پایگاه داده با حساسیت های مختلف نیازمند ذخیره سازهایی با پرفورمنس ها و ویژگی های مختلف هستند.
  • مشکلات در نسخه های قدیمی VMFS دلیل خوبی برای استفاده از RDM بودند ولی اکثر این مشلات رفع شده اند و دیگر وجود ندارند.

یک چلنج بزرگ برای بک آپ از دیتابیس های چند ترابایتی است. همچنین ورود حجم زیادی از دیتا در بازه زمانی کم نیز چالش بزرگی محسوب می گردد. در کل امکان گرفتن بک آپ های full از پایگاه داده های چند ترابایتی در Vmware وجود ندارد.

3 نوع سطح بندی متفاوت برای گرفتن بک آپ از دیتابیس اوراکل در vSphere وجود داره:

  • سطح اپلیکیشن (برای مثال استفاده از RMAN)
  • سطح vSphere (برای مثال استفاده از VMware snapshotها)
  • سطح ذخیره ساز (برای مثال استفاده از اسنپ شات ها در لایه ذخیره ساز، سینک و یا تقسیم دیسک ها و تکنلولوژیهای مشابه در برندهای مختلف سخت افزار)

راه حل های بک آپ مثل ORACLE RMAN و بک آپ از SQLها ارائه شده توسط دیتابیس اوراکل برای بک آپ بهترین سطح گارانتی شده برای گرفتن بک آپ هستند. اما در اغلب موارد سریعترین راه حل را ارئه نمی کنند.

گرفتن snapshot از ماشین مجازی به صورت لحظه ای راه حل بک آپ گیری ایده آل تری شاید باشند اما مشکلاتی را نیز به همراه دارند به عنوان مثال در هنگام پاک کردن یک snapshot از ماشین مجازی با لود کاری بالا امکان متوقف شدن و یا هنگ کردن ماشین مجازی برای مدت طولانی وجود دارد. (http://kb.vmware.com/kb/1002836)

در این لحظه حتی اگر ماشین متوقف نشود این اقدام می تواند تاثیر منفی بر روی پرفورمنس ماشین مجازی بگذارد.

در بین این 3 سطح شاید بتوان گفت snapshotهای گرفته شده توسط لایه ذخیره ساز بی دردسرترین و سریعترین راه حل ممکن هستند اما متاسفانه گرفتن snapshot توسط لایه ذخیره ساز توسط لایه مجازی ساز قابل کنترل نیست بنابراین هیچ جزییاتی از این اقدام در لایه مجازی ساز قابل شناسایی و پیگیری نیست.

یک بک آپ ایده آل از نظر شرکت Vmware برای پایگاه داده های اوراکل (به غیر از بک آپ در سطح اپلیکیشن) با لود کاری بسیار ادغام 3 سطح پشتیبان گیری باهم است برای 2 سطح زیر شرکت VMware راهکار ادغام ارائه داده است:

  • باید بتوان عملیات backup و clone گیری از ماشین را در لایه مجازی ساز ایجاد کرد.
  • باید با سریعترین حالت ممکن snapshotهای فوری برپایه تکنولوژی های ذخیره ساز ایجاد کرد.

تکنولوژی VMware vSphere Virtual Volumes یک تکنولوژی و راه حل شرکت VMware برای این ادغام است.

برای اطلاعات بیشتر به لینک محصول مراجعه کنید:

https://www.vmware.com/products/vsphere/virtual-volumes.html

استفاده از VMware vSAN

vSAN یک راه حل نرم افزاری ذخیره سازی کاملا سازگار برای ایجاد یک زیرساخت ذخیره ساز (SAN) کاملا مجازی است، vSAN یک معماری نرم افزاری کامل برای ارائه زیرساخت مجازی SAN به صورت کامل به جهت استفاده در سرورهای مجازی است. این زیرساخت با گروه بندی دیسک های لوکال ماشین های سخت افزاری ارائه یک زیرساخت کامل را با استفاده از انواع دیسک های SSD به جهت استفاده به عنوان کش خواندن/ نوشتن و انواع دیسک های لوکال را ارائه می کند.

vSAN می تواند فقط از دیسک های SSD یا دیسک های 15k و یا فقط از یک گروه دیسک و یا ترکیبی از آنها به جهت ارائه زیرساخت مجازی SAN استفاده کند.

vSAN از معماری دیسک های چندگانه برای راه اندازی زیرساخت استفاده می کند که به جهت دستیابی به پرفورمنس بالا از دیسک های مبتنی بر فلش باری کش کردن داده و از باقی دیسک ها برای ذخیره سازی پایدار داده استفاده می کند. ادمین ها می توانند ویژگی های ذخیره سازی را همانند ظرفیت، سرعت و در دسترس پذیری را به عنوان یک پالیسی در سطح هر VMDK مشخص نمایند.این پالیسی ها به صورت داینامیک می توانند بهینه شوند بسته به لود سیستم و ماشین مجازی از منابع کمتر یا بیشتری استفاده کنند.

دیتابیس اوراکل به صورت single instance و cluster یا(RAC) می توانند بر روی vSAN راه اندازی شوند. به جهت دسترسی به پرفورمنس مطلوب شرکت VMware توصیه کرده کارشناس storage بر فرآیند راه اندازی این زیرساخت نظارت داشته باشد.

۰۴ مهر ۰۰ ، ۱۱:۰۱ ۰ نظر
مهدی غفاری

VMware در مقابل Oracle - ذخیره سازی - قسمت دوم

تکنولوژی VMware vSphere Flash Read Cache

قابلیت VMware vFRC از VMware VSPhere نسخه 5.5 به ESXi اضافه شد. vFRC یک بخشی از زیرساخت ذخیره ساز هاست ESXi است که برای مدیریت سخت افزارهای ذخیره ساز به شکل flash که به صورت لوکال به سرور اتصال پیدا کرده اند مورد استفاده قرار می گیرد. این سخت افزارها می توانند شامل انواع مختلفی باشند (فلش کارت های قابل اتصال به سرور، انواه هاردهای SSD به شکل SAS و SATA) زیرساخت فلش vSphere به عنوان یک بازوی کمکی از تمام منابع سخت افزاری معرفی شده به عنوان یک منبع واحد در صورت نیاز استفاده می کند در این فرآیند خواندن از دیسک های اصلی به شدت کاهش پیدا می کند.

زیرساخت فلش ساخته شده توسط vSphere برای 2 هدف می تواند استفاده شود:

  • استفاده از کش برای درخواست های IO ماشین های مجازی
  • ذخیره سازی فایلهای SWAP ماشین هاست ESXi

Raw Device Mapping

هایپروایزر Vmware همچنین از RDM پشتیبانی می کند. RDM قابلیت دسترسی ماشین مجازی را به صورت مستقیم به هارد دیسک local و یا دسترسی به LUNهای SAN از طریق فیبر نوری یا iSCSI را ممکن می کند. RDM از طریق ایجاد یک لینک در فایل VMFS به صورت پراکسی دسترسی ماشین را به سخت افزار ممکن می کند. فایلهای مپ ایجاد شده دسترسی به فضاهای ارائه شده توسط سخت افزار را ممکن می کنند.

فایل های مپ دیوایس های خام نیستند اونها در حقیقت ارجاع هایی برای پیکربندی صحیح ماشین مجازی هستند.

پیکربندی RDM به 2 شیوه ممکن است:

Virtual compatibility mode

در این حالت به صورت کامل مجازی سازی در ایجاد مپ بین دستگاه ذخیره ساز و ماشین مجازی پیشتیبانی می گردد، حالت virtual مزایای زیادی رو برای VMFS ها میاره مثل advanced file locking برای data protection و استفاده از snapshotها

Physical compatibility mode

در این حالت شما به اکثر ویژگی های سخت افزار خود به صورت مستقیم دسترسی دارید. Vmkernel تمام دستورات ارسالی سیستم عامل به SCSI را برای سخت افزار ذخیره ساز ارسال می کند که البته همین موضوع می توان تمام اطلاعات لایه سخت افزار ذخیره ساز شما را برای ماشین مجازی مهمان افشا کند.

مقایسه VMFS و RDM

برای تصمیم گیری در مورد این موضوع که فایل های دیتای پایگاه داده شما بر روی VMFS ایجاد شوند و یا بر روی RDM شما نیازی به مقایسه سرعت در محیط خود نیستید.

البته این موضوع خیلی مهم است که شما کدام شیوه دسترسی را برای ارتباط اپلیکیشن خود با سخت افزار خود انتخاب می کنید. انتخاب دسترسی صحیح سرعت و کارایی اپلیکیشن شما را تا حد بالایی در اپلیکیشن های enterprise افزایش می دهد.

این موضوع توسط تست های بسیار توسط Vmware تایید شده است که نتیجه سرعت بر روی VMFS یا همان RDM مجازی با RDM فیزیکی تقریبا در بیشتر حالات عمومی یکسان است:

 دریافت فایل (performance_char_vmfs_rdm)

شرکت Vmware به شدت استفاده از VMFS را توصیه می کند اما ممکن است در حالاتی نیاز به RDM باشد برخی از تفاوت های VMFS و RDM را گردآوری کردیم تا انتخاب مناسبتری برای پروژه خود داشته باشید:

(همچنین برای بحث کاملتر در مورد این موضوع به مستند زیر مراجعه کنید.)

 دریافت (vsphere-esxi-vcenter-server-storage-guide) 

VMFS RDM
هر فضا می تواند میزبان چندین ماشین مجازی باشد (یا به صورت اختصاصی فقط به یک ماشین مجازی اتصال یابد.) مپ کامل فضای هر LUN یا فضا به حداقل یک ماشین مجازی ممکن است 
دارای ابزارهای سیاست گذاری ساده جهت افزایش فضای ذخیره سازی و دارای انعطاف پذیری و مدیریتی بیشتر  به طور معمول همیشه نیازمند LUNهای بیشتر برای افزایش فضا هستید و حداکثر توان بهره برداری از 256 LUN را دارید

به طور کامل از از کلاستر کردن هایی که نیازمند رزرو در iSCSI نیستد پشتیبانی می کند. یکی از موارد عدم پشتیبانی Oracle RAC است. برای پشتیبانی از این حالات باید flag مرتبط multi-writer غیرفعال گردد.
https://kb.vmware.com/s/article/1034165

به شکل مرسوم تکنولوژی RDM جهت پشتیبان گیری های لایه پایین توسط نرم افزارهای خارجی و ابزارهای replication در سطح بلاک نیاز است
پایین بودن سرعت در عملیات multi write توسط چندین ماشین و امکان ایجاد data corruption تکنولوژی RDM جهت مهاجرت آسان یک دیتابیس فیزیکی به ماشین مجازی بسیار کمک کننده است. همچنین در صورت درخواست تیم ساپورت اوراکل به آسانی قابلیت مهاجرت از ماشین مجازی به ماشین فیزیکی وجود دارد.
قابلیت جا به جایی نود ها بین ماشین ها در کلاستر اوراکل قابل استفاده برای Microsoft Cluster Server و Oracle Cluster

۰۴ مهر ۰۰ ، ۰۹:۵۸ ۰ نظر
مهدی غفاری

خطای ORA-65114: space usage in container is too high در datapatch

داشتم PSU با شماره Patch 32904851 - Database Release Update 19.12.0.0.210720 رو اپلای میکردم، بعد از اپلای طبق معمول شروع به زدن datapatch اون کردم که موقع انجام عملیات به یه خطای عجیب برخورد کردم:


Current state of release update SQL patches:
Binary registry:
19.12.0.0.0 Release_Update 210716141810: Installed
PDB PDB3:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.16.581942 PM
PDB APIGWYDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
PDB CDB$ROOT:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.07.436745 PM
PDB DEPLOYDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.18.406588 PM
PDB DFNDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
PDB DSTCHDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
PDB PDB1:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.10.490613 PM
PDB IMENDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.19.319451 PM
PDB OLTPDTNDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
PDB PDB$SEED:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
PDB PDB4:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.13.536972 PM
PDB PDB2:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.13.536972 PM
PDB SHATOOTCORE:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
PDB SVCGWYDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
Adding patches to installation queue and performing prereq checks...done
Installation queue:
For the following PDBs: CDB$ROOT PDB1 PDB2 PDB3 PDB4
No interim patches need to be rolled back
Patch 32904851 (Database Release Update : 19.12.0.0.210720 (32904851)):
Apply from 19.10.0.0.0 Release_Update 210108185017 to 19.12.0.0.0 Release_Update 210716141810
No interim patches need to be applied
For the following PDBs: PDB$SEED DEPLOYDB IMENDB SVCGWYDB APIGWYDB OLTPDTNDB DFNDB DSTCHDB SHATOOTCORE
No interim patches need to be rolled back
Patch 32904851 (Database Release Update : 19.12.0.0.210720 (32904851)):
Apply from 19.10.0.0.0 Release_Update 210108185017 to 19.12.0.0.0 Release_Update 210716141810
No interim patches need to be applied
DBD::Oracle::st execute failed: ORA-65114: space usage in container is too high
ORA-06512: at line 2 (DBD ERROR: OCIStmtExecute) [for Statement "BEGIN
INSERT INTO sys.dba_registry_sqlpatch_ru_info
(patch_id,
patch_uid,
patch_descriptor,
ru_version,
ru_build_description,
ru_build_timestamp,
patch_directory)
VALUES
(:patch_id,
:patch_uid,
:patch_descriptor,
:ru_version,
:ru_build_description,
TO_TIMESTAMP(:ru_build_timestamp, 'YYMMDDHH24MISS'),
:patch_directory);
COMMIT;
END;" with ParamValues: :patch_descriptor=OCIXMLTypePtr=SCALAR(0x27bfd28), :patch_directory='PK........J.▒R..$▒....▒M......32904851_rollback.sql▒.[s.H.@▒▒+x.▒.▒l▒U.M▒▒x.%q.-▒,gfg_T.▒L..@▒VR▒▒▒ .!.▒:.U.▒C
+.8:▒▒▒▒▒e:▒Ц▒▒?▒▒g..▒.▒▒▒&▒▒▒▒T;L▒▒.{Y.
▒2ɴ▒.▒.f.#▒.:▒KӶlK▒▒{=~s<.kQ▒▒
▒▒.3▒W▒▒▒...|8.h▒▒|▒▒.m2▒s▒▒▒▒.▒v▒▒"▒r▒7..▒..▒.'▒O:о}▒.▒)gY.Es▒▒4+^▒i..▒▒▒X▒▒▒x▒=Ϳ▒3/Y▒`-..▒▒
.▒.ϵ.▒.▒.n..<▒.▒▒▒▒▒▒3M▒▒▒(▒^▒▒Ϋ▒.▒▒ū%EyR-
▒▒▒.▒O.,▒S▒_~9x▒▒.▒x▒▒.▒▒▒ѻ▒▒▒CD..▒p▒T▒▒▒/▒s.,_▒.▒{gڳ▒▒▒tz▒|▒#.&'▒▒▒Ë▒▒▒p▒▒▒▒▒▒.▒▒▒▒É▒z߾.▒.▒.▒▒▒w▒▒▒9?;ծ.▒]▒▒▒<x%▒▒?;;▒.▒.▒
▒▒▒▒▒.▒.^.▒T▒...
M.▒▒...,▒f1M..^...▒..▒▒7.▒ʍ^▒.▒▒{▒▒▒o.'▒▒y.▒Էx▒▒.▒2.▒.._.▒▒z▒▒.▒▒.▒.▒.▒.▒▒..▒W▒▒|▒▒▒▒▒.;"..▒▒▒..▒{٫▒.p)K[▒ɭ+A~▒▒▒R..zxr1>..▒tz|6▒
AG.▒▒▒.▒▒▒▒▒▒▒P^_▒▒;▒▒H.▒,▒B▒K▒.▒▒▒▒j13G.▒m▒▒Y*▒▒▒▒Y.▒.gVEu.2z/.▒▒.v▒vrv~▒▒▒X.....O.▒▒W▒n▒5▒▒▒.▒r▒x.a▒|▒
▒o▒=ٻ▒e"▒▒k.▒ir6..▒▒.
▒LQ.▒I&▒▒▒UAZ▒h8▒▒.▒▒.X▒.kh▒:▒i
'ө9▒.▒▒p▒/▒.▒▒..isf
▒▒.N▒Ӿm▒f.▒..▒▒▒-▒..▒▒▒?.▒VF▒O▒▒▒u▒.▒▒.X▒#▒4F▒..▒▒▒u▒v.▒▒6N▒Scd▒..▒..▒.3Mc▒8{.(.▒G▒▒▒▒▒▒H▒;.▒~▒VN.D}▒▒CX▒y..▒.▒8.Q▒▒▒<▒:.▒..`▒▒"1mk(os▒▒c.#▒g g.▒1▒▒.M...', :patch_id='32904851', :patch_uid='24343243', :ru_build_description='Release_Update', :ru_build_timestamp='210716141810', :ru_version='19.12.0.0.0'] at /u01/oracle/product/19c/db_1/sqlpatch/sqlpatch.pm line 5841.

Please refer to MOS Note 1609718.1 and/or the invocation log
/u01/oracle/cfgtoollogs/sqlpatch/sqlpatch_5848_2021_09_20_19_12_46/sqlpatch_invocation.log
for information on how to resolve the above errors.
SQL Patching tool complete on Mon Sep 20 19:13:09 2021

این خطا با دستورات زیر رفع شد:

alter pluggable database PDB1 storage unlimited;
alter pluggable database PDB2 storage unlimited;
alter pluggable database PDB3 storage unlimited;
alter pluggable database PDB4 storage unlimited;

 

۲۹ شهریور ۰۰ ، ۱۹:۳۳ ۰ نظر
مهدی غفاری

VMware در مقابل Oracle - ذخیره سازی - قسمت اول

راهنمای کلی

جدول زیر توضیحاتی در رابطه با best practices های اعلامی توسط شرکت Vmware برای پایگاه داده اوراکل ارائه می کند:

ردیف

توصیه شده

علت توصیه

1

فعال سازی jumbo frames برای ذخیره ساز های مبتنی بر IP مانند iSCSI یا NFS

فعال سازی Jumbo frame ها بر روی بستر شبکه باعث افزایش ظرفیت بار ترافیک شبکه و بزرگتر شدن هر پکیج می شوند. این ویژگی همیشه برای افزایش پرفورمنس پیشنهاد می گردد.

2

ساخت یک datastore اختصاصی برا سرویس دهی مجزا به پایگاه داده

ایجاد datastore های اختصاصی همانند ایجاد LUNهای اختصاصی برای پایگاه داده در زمان استفاده از تکنولوژی VMFS است. با انجام این کار سرعت IO ورودی و خروجی افزایش خواهد یافت.

3

استفاده از تکنولوژی VMware RDM برای دیتابیس اوراکل

برای استفاده بهتر و بالا بردن سرعت استفاده از تکنولوژی RDM برای دیتابیسها با لود بالا توصیه میگردد.

4

استفاده از تکنولوژی Vmware vSphere VMFS برای دیتابیس اوراکل

برای مدیریت بهتر فضا و استفاده از تکنولوژی های Vmware HA استفاده از VMFS در دیتابیسهای تست و آزمون و با لود پایین توصیه میگردد.

5

تراز بودن سکتورهای VMFS با دیسک های سخت افزاری

مانند تمام فایل سیستم های رایج فایل سیستم VMFS نیز اگر در پارتیشن بندی پارتیشن align دیسک ها نشود می تواند مشکلاتی در ذخیره سازی (تا 40 درصد افت سرعت) و خواندن اطلاعات (تا 25 درصد افت سرعت) برایش رخ دهد. توصیه شرکت Vmware ساخت VMFSها تنها با استفاده از رابط VMware vCenter است تا به صورت خودکار پارتیشنهای ساخته شده align شوند.

6

استفاده از Oracle ASM

تکنولوژی Oracle ASM ادغام فناوری فایل سیستم های کلاستری و مدیریت فضای منطقی برای مدیریت فایلهای دیتابیس اوراکل است. ASM ساده سازی مثال زدنی جهت ذخیره سازی فایل های دیتابیس هنگام اضافه شدن یک سخت افزار جدید ذخیره سازی بدون پایین اومدن سرعت و یا قطعی دارد.

7

هنگام پیکربندی پایگاه داده اوراکل از مستندات فنی و best practice های شرکت سازنده ذخیره ساز استفاده کنید

تکنولوژی Oracle ASM نمی تواند محل مطلوب جهت ذخیره سازی داده ها را بر روی دیسک های خوب در لحظه مشخص کند. پس Oracle ASM جایگزینی برای عدم داشتن مشاور و کارشناس ذخیره سازی متخصص نیست.

8

استفاده از متخصص های ذخیره سازی در طراحی زیرساخت ذخیره سازی پایگاه داده

شما جهت طراحی مطلوب حداقل نیازمند افراد با تخصص های: مدیر پایگاه داده اوراکل، مدیر ذخیره سازی با تخصص بر روی تجهیزات مورد استفاده، مدیر شبکه، مدیر Vmware و مدیر محصول هستید.

9

استفاده از آداپتورهای پاراویرچوالیزیشن SCSI جهت ذخیره سازی دیتافایلهای پایگاه داده اوراکل با لود کاری بالا

این کنترل به صورت پاراویرچوالیزیشن جهت پشتیبانی از لود بالای ذخیره سازی IO و حداقل مصرف پردازش به خصوص برای محیط های دارای SAN طراحی شده است.

مفاهیم ذخیره سازی در VMware

ذخیره سازی مجازی در Vmware  را می توان در 3 لایه خلاصه سازی کرد:

  1. لایه ذخیره ساز که در پایینترین بخش قرار دارد، شامل دیسک های فیزیکی است که به صورت دیسک های منطقی و یا LUNهای جداگانه به لایه بعدی داده شده اند.
  2. لایه بعدی توسط vSphere برای ماشین مجازی تعریف میگردد. LUNهای قابل دسترس برای هاست ESX / ESXi به صورت datastore رزرو شده اند و پارتیشن های ایجادی به صورت فایلهای VMFS در اختیار ماشین مجازی قرار میگیرند.
  3. لایه بعدی پارتیشن های ایجادی در سیستم عامل ماشین مجازی مهمان هستند که بر روی فایلهای VMFS یا به صورت مستقیم بر روی لایه اول قرار دارند.

هایپروایزر شرکت Vmware یا همان VMware ESXi دارای 2 روش ایجاد دسترسی جهت ذخیره سازی بر روی دیسک های Local یا SAN است.

Virtual Machine File System (VMFS)

VMFS یک فایل سیستم کلاستر است که برای ذخیره سازی دیسک های ماشینهای مجازی بهینه شده است. ساختار هر ماشین مجازی به صورت یک مجموعه فایل کپسولی است و فایل VMFS برای دیسک این ماشین ها بر روی کنترلرهای مجازی SCSI مورد استفاده قرار می گیرد.

مزیت فایل سیستم کلاستر VMFS پشتیبانی از تکنولوژی های ESXi نظیر vSphere vMotion, DRS و vSphere HA جهت مدیریت حداکثر پایداری ماشینهای مجازی در سطح Host است.

سیاست پیش‌فرض شرکت Vmware استفاده از VMDK به صورت صفر شده thick provisioned lazy zeroed است که در آن بلاک های پدر VMFS با هر بار درخواست write با مقدار 1 مگابایت گرفته می‌شوند.

در اینجا با توجه به درخواست گرفتن فضا بعد از هر درخواست سرویس یک نوع پنالتی جهت جریمه write برای vmdk وجود دارد که می‌تواند بر عملیات‌های پایگاه داده در زمان پیک اثر منفی بگذارد، مثل عملیات‌های write و read که ازtablespace  یا tempdb های موقت استفاده میکنند و یا بارگذاری بالک از جداول و ایندکس ها.

هایپروایزر VMware قابلیت ساخت 3 نوع دیسک مجازی را دارد که برای آشنایی بیشتر به آن پرداخت میگردد:

روش اول Thin Provisioned

از مزایای ایجاد کردن Thin Provisioned می توان به سرعت بالای ایجاد (Faster Provision) و اشغال فضای دیسک بر اساس بالا رفتن میزان فضای مورد نیاز VM اشاره کرد. در کنار این مزایا ، معایبی نیز به Thin Provisioned وارد است که از جمله آنها می توان به کاهش کارایی VM با توجه به Overhead ای که Metadata ها بر روی VM دارند و همچنین Overhead ای که فرآیند های نوشتن بر روی دیسک برای این ساختار ایجاد می کنند اشاره کرد از طرفی اگر ظرفیت VM شما به اندازه ای بالا برود که از Provision در نظر گرفته بیشتر شود باعث ایجاد Downtime و اشغال زیاد منابع VM خواهد شد.

از همه مهمتر اینکه شما اگر دیسک های مجازی خود را در حالت Thin Provisioned قرار دهید دیگر نمی تواند از امکانات Clustering در ساختار مجازی سازی خود استفاده کنید. زمانیکه VSphere یک دیسک Thin Provisioned ایجاد می کند فقط مقدار کمی Metadata در Datastore ذخیره می کند.

در این حالت هیچگونه فضایی بصورت یکباره از Datastore گرفته نمی شود ، زمانیکه فرآیند نوشتن بر روی دیسک انجام می شود ، VSphere ابتدا اطلاعات مربوط به Metadata ای که مربوط به فایل VMDK است را بروز می کند و در نهایت بلوک های جدیدی از داده را از Datastore دریافت و در آن اطلاعات را می نویسد. این عملیات در محل هایی که فرآیند های نوشتن و خواندن زیادی انجام می شود باعث بالا رفتن Overhead می شود.

Thin Provision ها دارای پایینترین کارایی از نظر سیستم در بین سه حالت و قالب دیسک هایی هستند که در VMware وجود دارد. البته در کنار همین معایب در محیط هایی که محدودیت استفاده از فضا دارند این نوع دیسک بسیار کاربردی است، دیسک های Thin Provisioned قابلیتی دارند که شما می توانید تا زمانیکه فضای واقعی دیسک شما پر نشده است از فضای مجازی موجود بر روی دیسک استفاده کنید.

 

برای مثال شما اگر 10 عدد VM داشته باشید که هر کدام از آنها به 50 گیگابایت فضا نیاز داشته باشند اما فضای Datastore شما تنها 100 گیگابایت باشد شما می توانید هر 10 عدد VM را با ظرفیت 50 گیگابایت ایجاد و راه اندازی کنید. در این حالت به یکباره فضا از Datastore دریافت نمی شود

و به مرور زمان با اضافه شدن حجم داده ها به VM ها تا مرز 100 گیگابایت شما می توانید از همه VM های خود همزمان استفاده کنید. اینکار باعث کاهش هزینه ها می شود ، برعکس Thick Provision که به یکباره با در نظر گرفتن فضا ، همه فضا را به یکباره از Datastore می گیرد.

روش دوم Thick Provision Lazy Zeroed

از مزایای ایجاد کردن Thick Provisioned Lazy Zeroed سرعت بیشتر ایجاد (Faster Provision) نسیت به Thick Provision Eager Zeroed است. این نوع دیسک های مجازی کارایی بهتری نسبت به Thin Provisioned دارند اما به نسبت سرعت ایجاد شدن آنها از Thin Provision کمتر است.

همچنین از دیگر معایب این نوع دیسک های مجازی کارایی و سرعت پایینتر نسبت به Thick Provisioned Eager Zero می باشد ، این نوع دیسک های مجازی همانند Thin Provisioned قابلیت Clustering از نوع FT را پشتیبانی نمی کنند اما کلاسترینگ از نوع HA را پشتیبانی می کنند.

زمانیکه VSphere یک دیسک از این نوع ایجاد می کند ، حداکثر اندازه ای که می تواند به فایل VMDK اختصاص دهد را به یکباره به آن می دهد اما دیگر هیچ کاری انجام نمی دهد. با دسترسی پیدا کردن به هر قسمت از بلاک های دیسک VSphere ابتدا بلاک را آماده و داده ها را در آن می نویسد.

سرعت و کارایی دیسک های مجازی که از نوع Thick Provisioned Lazy Zeroed هستند به دلیل ایجاد کردن Overhead در دیسک ها از Thick Provisioned Eager Zeroed کمتر است. بصورت خلاصه بعد از اینکه دیسک بصورت Lazy Zeroed ایجاد شد فضای متناسب با آن از Datastore گرفته می شود اما فضا پاکسازی نمی شود.

به محض اینکه شما بخواهید داده ای به این دیسک اضافه کنید فضا نیز ابتدا پاکسازی می شود و سپس داده های شما نوشته می شود که این به نوعی دوباره کاری برای VSphere ایجاد خواهد کرد.

پیشنهاد شرکت Vmware جهت راه اندازی پایگاه داده RDBMS اوراکل بر روی هایپروایزر ESXi در صورت استفاده از تکنولوژی VMware vSphere Storage APIs و تمایل به VMFS استفاده از این نوع دیسکThick Provision Lazy Zeroed است.

مزایای VMware vSphere Storage APIs

  • افزایش سرعت کلون گیری با Hardware-accelerated (کلون گیری از بلاک ها به صورت Full Copy/XCOPY)
  • قابلیت مدیریت بهینه سازی لاک ها (این همان Atomic Test and Set [ATS] است)
  • صفر کردن نوشتن بلاک ها همانند صفر کردن فیزیکی دیسک ها
  • قابلیت دوباره گرفتن فضای دیسک ها برای استفاده از بلاک هایی که دیگر نیازی به آنها نیست
  • قابلیت پاک کردن بلاک ها برای استفاده از بلاک هایی که دیگر نیازی به آنها نیست

روش سوم Thick Provisioned Eager Zeroed

در این روش تمام فضای درخواستی با Overwrite شدن با 0 باعث کاهش ریسک های امنیتی بر روی این نوع دیسک های مجازی می شود.

با استفاده از این نوع دیسک شما می توانید از قابلیت های Clustering ای VMware Fault Tolerance استفاده کنید تنهای عیبی که می شود به این نوع دیسک گرفت زمان طولانی تر نسبت به سایر دیسک ها برای ایجاد شدن یا Provision Time بالاتر می باشد.

زمانیکه VSphere یک دیسک از نوع Provisioned Eager Zeroed ایجاد می کند ، حداکثر مقدار فضای ممکن برای دیسک را به یکباره به فایل VMDK اختصاص می دهد سپس تمامی فضاهایی که بر روی دیسک وجود دارند را صفر می کند. برای مثال اگر شما یک فایل VMDK را بصورت Thick Provisioned Eager Zeroed ایجاد کنید و 80 گیگابایت فضا برای آن در نظر بگیرید.

VSphere بلافاصله از دیسک شما 80 گیگابایت می گیرد و به فایل VMDK اختصاص می دهد و تمامی فضای 80 کیگابایت را با صفر پر می کند.زمانیکه تمامی فضاهای خالی با صفر پر شدند، Thick Provisioned Eager Zeroed مطمئن می شوند که در هنگام نوشتن اطلاعات داخل دیسک هیچگونه ریسک امنیتی به وقوع نمی پیوندد. Thick Provisioned Eager Zeroed Disk ها از بهترین کارایی در تمامی فایل های VMDK برخوردارند.

زمانیکه قرار است داده ای بر روی دیسک های Eager Zeroed انجام شود VSphere تنهای کاری که باید بکند نوشتن اطلاعات است و هیچ کار اضافی لازم نیست انجام شود ، همین امر باعث برتری این نوع دیسک نسبت به Thin Provisioned و Lazy Eager شده است.

پیشنهاد شرکت Vmware جهت راه اندازی پایگاه داده RDBMS اوراکل بر روی هایپروایزر ESXi در صورت عدم استفاده از تکنولوژی VMware vSphere Storage APIs و تمایل به VMFS استفاده از این نوع دیسک است.

نکته: در زمان راه اندازی Oracle RAC بر روی VMFS جهت شبیه سازی ذخیره سازی اشتراکی استفاده از Thick Provisioned Eager Zeroed الزامی است.

http://kb.vmware.com/kb/1034165

۱۴ شهریور ۰۰ ، ۰۹:۰۶ ۰ نظر
مهدی غفاری

VMware در مقابل Oracle - مقدمه

این سری مطلب صرفا برای آشنایی ادمین های دیتابیس اوراکل با زیرساخت مجازی شرکت VMware بر مبنای مستندات رسمی شرکت VMware است.

تکنولوژی مجازی سازی VMware راه حلی با مزایای بسیار برای DBAهای اوراکل هستش. مجازی ساز VMware یک لایه میانی بین منابع سخت افزاری و اپلیکیش نیازمند به منبع و سیست عامل آن قبل از دسترسی مستقیم به سخت افزار ایجاد می کند. این لایه مزایای زیر را برای اپلیکیشن شما به همراه دارد:

  • Consolidation = تکنولوژی VMware اجازه می دهد شما چندین سرور مجازی برای کارکردهای مختلف در یک سرور فیزیکی داشته باشید و تاثیر عملکرد و پرفورمنس بر روی آن ها اندک یا ناچیز باشد.
  • Ease of provisioning = یعنی آسان شدن تامین کارهایی که به صورت فیزیکی نیازمند برطرف سازی پیچیدگی های زیاد است. مجازی سازی یک اپلیکیشن را در یک image قرار می دهد و باعث می شود هزینه کپی و انتقال و استقرار جدید ماشین مجازی بسیار کاهش یابد.
  • Manageability = مدیریت بلادرنگ یعنی ماشین های مجازی را می توان بدون خرابی یا ایجاد مشکل با استفاده از تکنولوژی VMware vSphere® vMotion بدون قطعی از سروری به سرور دیگر جا به جا کرد. این تکنولوژی به شما در انجام عملیات های متداول برای تعمیر و نگهداری در زمان خرابی های برنامه ریزی شده کمک بسیاری می کند.
  • Availability = اگه یه خرابی برنامه ریزی نشده پیش بیاد تکنولوژی VMware vSphere High Availability (HA) ماشین مجازی های آسیب دیده را بر روی یک کلاستر VMware دیگر بلافاصله راه اندازی مجدد می کند. تکنولوژی VMware vSphere Fault Tolerance (FT) با ویژگی هایی برای از دست ندادن داده و حداقل داون تایم در صورت خرابی سخت افزار سرور برای ماشین های مجازی دسترسی پذیری مداوم را فراهم می کند.

حالا بیاین ببینیم بین دیتابیس اوراکل و تکنولوژی شرکت VMware جهت مجازی سازی چه رابطه هایی وجود داره که ادمین های دیتابیس اوراکل رو از رفتن بر روی این تکنولوژی در محیط های عملیاتی بزرگ دچار استرس میکنه:

اوراکل برای اجرای محصولات نرم افزاری خود (به جهت مشتری مداری مشتریان دارای لایسنس و پشتیبانی فعال) بر روی تکنولوژی های شرکت VMware یک قرارداد مستقیم با شرکت VMware امضا کرده که برای اجرا و عملیاتی کردن تکنولوژی های فعال اوراکل و دارای پشتیبانی فعال بر روی تکنولوژی های شرکت VMware مشتریان دغدغه نداشته باشند. 

اما در این قرارداد آمده که اگه مشتریان محصولات اوراکل به یک issue اساسی برخورد کنند و پشتیبانی اوراکل تشخیص دهد مشکل ایجاد شده ناشی از محصولات اوراکل نیست یا در محیطی غیرمستقیم که اوراکل بر روی اون تست ها و آزمون های خود را انجام نداده است اجرا شده باشد، شرکت اوراکل با توجه به قرارداد با شرکت VMware مشتریان را به پشتیبانی از سمت شرکت VMware ارجاع می دهد و برای حل مشکل شرکت اوراکل به شرکت VMware کمک خواهد کرد. با این وجود مشتریان اوارکل باید دقت کنند سیاست لایسنس و پشتیبانی محصولات اوارکل تاثیری بر سیاست های لایسنس و پشتیبانی شرکت VMware ندارد.

(متن فوق از مستند: Support Position for Oracle Products Running on VMware Virtualized Environments در متالینک اوراکل)

تجربه من نشون داده اوراکل تعهد خودش رو به مشتریان حتی در مواردی که نیاز به پشتیبانی مستقیم است تا حد بالایی حفظ می کند.

۰۹ شهریور ۰۰ ، ۱۵:۰۲ ۰ نظر
مهدی غفاری

VMware در مقابل Oracle - پیروز میدان کیست؟

بحث نصب دیتابیس اوراکل بر روی VMware ESXi همیشه یکی از اون مواردی هستش که پیروزی در سازمان ها نداره! یکبار میخوام این بحث رو به صورت کاملا فنی و تکنیکی باز کنم تا باهم بیشتر به مزایا و معایب ماشین های مجازی اشراف داشته باشیم و بتونیم مثل هر تکنولوژی خوب دیگه ای در نرم افزار از دیدگاه فنی این موضوع رو بلد باشیم و بدون تعصب به مسیر خوبمون جهت ارائه سرویس هایی با کیفیت بالا و حداکثر پایداری ادامه بدیم.

 

VMware در مقابل Oracle - مقدمه

VMware در مقابل Oracle - ذخیره سازی - قسمت اول

VMware در مقابل Oracle - ذخیره سازی - قسمت دوم

VMware در مقابل Oracle - ذخیره سازی - قسمت سوم

VMware در مقابل Oracle - ذخیره سازی - قسمت چهارم

VMware در مقابل Oracle - ذخیره سازی - تست لود

VMware در مقابل Oracle - ذخیره سازی - نتیجه گیری

VMware در مقابل Oracle - ذخیره سازی - تاثیر Cache Page Size

۰۸ شهریور ۰۰ ، ۱۰:۴۱ ۰ نظر
مهدی غفاری

ساخت کاربر مجزا برای export و Import در Oracle Datapump

یکی از روسه های رایج جهت انتقال اسکیما در اوراکل استفاده از ابزار Oracle Datapump هستش، به طور معمول خیلی از DBA ها از کاربر sys و یا system برای عملیات های datapump استفاده میکنند اما بهتره که کاربر این ابزار جداسازی شود. برای ساخت کاربر برای این ابزار می توانیم به شیوه زیر که یک مثال است عمل کنیم:

create users c##exportuser identified by <strong-password>;
alter user c##exportuser quota unlimited on users;
grant exp_full_database to c## c##exportuser;
grant create session to c##exportuser;
grant read, write on directory DUMP to c##exportuser;
۰۸ شهریور ۰۰ ، ۰۸:۵۷ ۰ نظر
مهدی غفاری

انتقال DATAPUMP با استفاده از DBLINK

یکی از روش های رایج برای انتقال اسکیما استفاده از Datapump اوراکل هستش. به طور معمول شما باید از سرور مبدا یک فایل Datapump تهیه کنید و با ابزارهایی مثل SCP اون رو به سرور مقصد انتقال بدید و سپس اقدام به IMPORT اون کنید.

یک روش ساده دیگه برای انجام این کار استفاده از TNS در سرور مقصد هستش به این ترتیب که شما اول یک DBLINK در سرور مبدا (در CDB و یا اون PDB) ایجاد میکنید بعد یک EXPORT با دی بی لینک بر روی سرور مقصد میگیرید که این عمل باعث این میشه که فایل شما روی سرور مقصد ایجاد بشه بعد اقدام به IMPORT فایل می کنید.

CREATE PUBLIC DATABASE LINK DBT_LINK
CONNECT TO system IDENTIFIED BY dba1
USING '<TNS_Origin>'

expdp system@<TNS_DEST> directory=DATA_PUMP_DIR LOGFILE=MyExpdp.log network_link=DBT_LINK schemas=MyRemoteDBSchema1,MyRemoteDBSchema2
impdp system@<TNS_DEST> directory=DATA_PUMP_DIR LOGFILE=MyImpdp.log schemas=MyRemoteDBSchema1,MyRemoteDBSchema2

http://www.oracle-wiki.net/startdocshowtousedatapumpoveradatabaselink

۰۳ شهریور ۰۰ ، ۰۷:۴۲ ۰ نظر
مهدی غفاری

ایمیج های از پیش ساخه شده Oracle در Virtualbox

اوراکل یکسری ایمیج‌های از پیش ساخته شده برای virtualbox در دسترس developerها قرار داده که می‌تونید از طریق لینک‌های زیر به اونها دسترسی داشته باشید:

 

  

https://www.oracle.com/downloads/developer-vm/community-downloads.html

https://www.oracle.com/middleware/technologies/obiee-samples-downloads.html

https://www.oracle.com/middleware/technologies/obiee-samples-v506-downloads.html

۱۶ آبان ۹۹ ، ۱۷:۰۹ ۰ نظر
مهدی غفاری

طرح تست ویژگی‌های جدید دیتابیس اوراکل 20C

اگه مطالب قبلی من رو دنبال کرده باشید من در یک طرح محدود برای تست فیچرهای اوراکل 20C هستم (جمعا ۳۳ ویژگی) از اونجایی که زمان من برای تست محدوده (حداکثر تا تاریخ 2020-Nov-20) و فیچرها زیاد هستن و من میخوام تمام این ویژگی‌ها رو به فارسی مستند کنم از تیم اوراکل برای حداکثر تا ۵ نفر اجازه گرفتم که در این طرح همراه من باشند که این فیچرها رو باهم تست و در این وبلاگ مستندسازی کنیم.

لازم به ذکره مطالب هر نفر به اسم خودش منتشر میشه و هر روز تست و مستند سازی یک ویژگی الزامی هست.

پس اگه مشتاق جزو اولین نفراتی باشید که اوراکل 20C رو تست می‌کنند از طریق تلگرام به من پیام بدید.

@MahdiGhaffari94

۲۶ مهر ۹۹ ، ۱۱:۱۱ ۰ نظر
مهدی غفاری