داستانهای واقعی: افزایش فضای shared pool

یک RAC سه نود بر روی اوراکل نسخه 12.2 داریم. مدتی بود در وقت های پیک کاری اپلیکیشن، با ویت ایونت gc current block 2-way و ... و با مقدار بالا برخورد میکردم به نحوی که کارکرد اپلیکیشن رو مورد تاثیر خود قرار داده بود. از طرفی تمام موارد مرتبط با GC در کلاستر رو با دقت و وسواس بالا با توجه به آخرین Best Practiceها پیکربندی و بازبینی کرده بودم (به خصوص پارامترهای مرتبط با LMS مانند GCS_SERVER_PROCESSES) و با مانیتورینگ شبکه و سرعت Interconnect هام از سرعت و وضعیت خوب اونها مطمئن بودم همچنین با توجه به مشاهدات محیطی به این نتیجه رسیده بودم که در طول 2 ماه کارکرد اپلیکیشن تنها در انتهای بازه های پیک اپلیکیشن این مشکل دیده میشد پس این موضوع کنجکاوی من رو برای این که بفهمم مشکل کجا بود بیشتر کرد.

تو بررسی هام از طریق Memory Advisor در Enterprise Manager متوجه شدم که در این روزها فضای shared pool به طرز قابل توجهی بالا میره و فضای buffer cache بسیار کوچیک میشه پس با این فرض همه چیز منطقی به نظر میومد. چون با رشد فضای shared pool فضای کافی برای buffer cache نبود.

زمانی که سیستم در وضعیت و پرفورمنس مناسب قرار داشت

 

دستورات کاربردی ابزار Srvctl

Srvctl یک ابزار شناخته شده برای add، remove، relocate و مدیریت سرویسهای crs مختلف یا کامپوننت های RAC است.

1. STOP DATABASE

SYNTAX – srvctl stop database -d db_name [-o stop_options] where stop_options is normal/immediate(default)/transactional/abort

e.g

srvctl stop database -d PRODB -o normal
srvctl stop database -d PRODB -o immediate
srvctl stop database -d PRODB -o transactional
srvctl stop database -d PRODB -o abort

2. START DATABASE
SYNTAX – srvctl start database -d db_name [-o start_options] where start_option is nomount/mount/open(default)

e.g

srvctl start database -d PRODB -o nomount
srvctl start database -d PRODB -o mount
srvctl start database -d PRODB -o open

قابلیت Gradual Database Password Rollover

برای تغییر پسوردها شما میتوانید از قابلیت جدیدی که در نسخه 19.12 به بعد معرفی شده است (Gradual Database Password Rollover) استفاده کنید . در این روش امکان استفاده همزمان از رمز عبور قبلی و رمز عبور جدید برای مدت زمان مشخصی که در پروفایل آن کاربر تعریف میشود وجود دارد . در این فاصله زمانی میتوان نسبت به تعویض رمز عبور کاربر در پایگاه داده و بر روی تنظیمات برنامه اقدام نمود. پس از سپری شدن زمان مقرر شده امکان استفاده از رمز عبور قبلی وجود نخواهد داشت .

ابتدا پارامتر PASSWORD_ROLLOVER_TIME را در پروفایل کاربر تنظیم میکنیم . کمترین میزان برای پارامتر PASSWORD_ROLLOVER_TIME یک ساعت و بیشترین مقدار 60 روز میباشد . در این مثال مدت زمان یک ساعت در نظر گرفته شده است .

ALTER PROFILE USER_PROFILE LIMIT PASSWORD_ROLLOVER_TIME 1/24;

توجه
تمامی یوزر هایی که از پروفایل استفاده میکنند شامل Policy جدید میشوند .
Session های که به پایگاه داده متصل هستند با تغییر پسورد دچار اختلال نمیشوند.

این پارامتر می تواند حداقل مقدار 1 ساعت (1/24) و حداکثر 60 روز را داشته باشد.

پسورد کاربر مورد نظر را تغییر داده .

ALTER USER USERSERVICES IDENTIFIED BY NEW_PASSWORD;

در این مرحله نسبت به تغییر پسورد در فایل های مربوط به تنظیمات برنامه اقدام کنید .
پس از تغییرات در تنظیمات برنامه در صورتی که مدت زمان پارامتر PASSWORD_ROLLOVER_TIME به اتمام رسیده باشد امکان استفاده از رمز عبور قبلی وجود ندارد . همچنین با استفاده از دستور زیر میتوان زودتر از موعد مقرر شده Policy تنظیم شده را منقضی نمود .

ALTER USER USERSERVICES EXPIRE PASSWORD ROLLOVER PERIOD;

جهت غیر فعال کردن این قابلیت کافیه مقدار پارامتر را به 0 تغییر داد.

ALTER PROFILE USER_PROFILE LIMIT PASSWORD_ROLLOVER_TIME 0;

تغییر تنظیمات مربوط به Maintenance Windows

هنگام ساخت پایگاه داده با استفاده از ابزار DBCA و انتخاب Template های از پیش ساخته شده ، منطقه زمانی Scheduler به صورت پیش فرض بر روی UTC -07:00 قرار میگیرد که منجر به اجرا شدن تمامی Maintenance Windows با منظقه زمانی Los Angeles میشود . همچنین در تقویم میلادی روز های شنبه و یکشنبه تعطیل میباشد لذا به طور پیش فرض در این دو روز Task های مربوط به Maintenance Windows منابع و زمان بیشتری را مورد استفاده قرار میدهند .
دستورات زیر شامل : تغییر منطقه زمانی به Asia/Tehran ، تغییر زمان شروع به ساعت 2 بامداد ، تغییر مدت زمان اجرا هر Task به 1 ساعت در Container(CDB$ROOT) میشود .

ALTER SESSION SET CONTAINER=CDB$ROOT;
 
 BEGIN
--DISABLE WEEKEND AND WEEKNIGHT SCHEDULER
DBMS_SCHEDULER.DISABLE('WEEKNIGHT_WINDOW');
DBMS_SCHEDULER.DISABLE('WEEKEND_WINDOW');
--DISABLE SCHEDULER BEFORE CHANGING ATTRIBUTE
DBMS_SCHEDULER.DISABLE('SATURDAY_WINDOW');
DBMS_SCHEDULER.DISABLE('SUNDAY_WINDOW');
DBMS_SCHEDULER.DISABLE('MONDAY_WINDOW');
DBMS_SCHEDULER.DISABLE('TUESDAY_WINDOW');
DBMS_SCHEDULER.DISABLE('WEDNESDAY_WINDOW');
DBMS_SCHEDULER.DISABLE('THURSDAY_WINDOW');
DBMS_SCHEDULER.DISABLE('FRIDAY_WINDOW');
--CHANGE DEFUALT TIME ZONE FOR SCHEDULER
DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE('DEFAULT_TIMEZONE', 'ASIA/TEHRAN');
--CHANGE START_TIME AND DURATION ATTRIBUTE
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'SATURDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('SATURDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=SAT;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'SUNDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('SUNDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=SUN;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'MONDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('MONDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=MON;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'TUESDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('TUESDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=TUE;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'WEDNESDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('WEDNESDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=WED;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'THURSDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('THURSDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=THU;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
DBMS_SCHEDULER.SET_ATTRIBUTE(NAME => 'FRIDAY_WINDOW', ATTRIBUTE => 'DURATION', VALUE => NUMTODSINTERVAL(1, 'HOUR'));
DBMS_SCHEDULER.SET_ATTRIBUTE('FRIDAY_WINDOW', 'REPEAT_INTERVAL', 'FREQ=WEEKLY;BYDAY=FRI;BYHOUR=02;BYMINUTE=0;BYSECOND=0');
--Enable Scheduler
DBMS_SCHEDULER.ENABLE('SATURDAY_WINDOW');
DBMS_SCHEDULER.ENABLE('SUNDAY_WINDOW');
DBMS_SCHEDULER.ENABLE('MONDAY_WINDOW');
DBMS_SCHEDULER.ENABLE('TUESDAY_WINDOW');
DBMS_SCHEDULER.ENABLE('WEDNESDAY_WINDOW');
DBMS_SCHEDULER.ENABLE('THURSDAY_WINDOW');
DBMS_SCHEDULER.ENABLE('FRIDAY_WINDOW');
END;
/ 

تغییر UNDO_RETENTION در PDB

از نسخه  19.9  به بعد تغییر برخی از پارامتر ها (در اینجا پارامتر مورد نظر UNDO_RETENTION  میباشد ) در Container Root (CDB$ROOT)  منجر  به تغییر آن پارامتر در بقیه PDB ها نمیشود  . از نسخه 12.2.0.1 به صورت پیش فرض هر PDB  دارای UNDO_TBS  مخصوص به خود میباشد (منظور local undo only  که تنظیم پیش فرض به هنگام ساخت یک PDB  جدید است ) از این رو هر PDB تنظیم UNDO  مخصوص به خود را دارد. برای تغییر پارامتر UNDO_RETENTION در تمامی Instance از دستور زیر استفاده کنید .

ALTER SYSTEM SET UNDO_RETENTION=10 CONTAINER=ALL SCOPE=BOTH;

دستور بالا در محیط دیتاگارد به دلیل Read-Only  بودن PDB با خطا مواجه میگردد . در محیط دیتاگارد از دستور زیر استفاده میگردد .

ALTER SESSION SET CONTAINER=CDB$ROOT;
ALTER SYSTEM SET UNDO_RETENTION=10 SCOPE=BOTH;
ALTER SESSION SET CONTAINER=SHATOOTPDB;
ALTER SYSTEM SET UNDO_RETENTION=10 SCOPE=BOTH;

لازم به ذکر است که هنگام تغییر پارامتر های داخل PDB   اگر از SCOPE=SPFILE  و یا SCOPE=BOTH  استفاده شود ، آن تغییر  در Data Dictionary  های PDB  و فایل تعریف XML  آن PDB ذخیره میشود  و بر روی SPFILE  تغییری ایجاد نمیکند . برای مشاهده پارامتر های تغییر یافته داخل PDB   از کوئری زیر استفاده شود .

SELECT PS.DB_UNIQ_NAME , PS.PDB_UID , P.NAME AS PDB_NAME , PS.NAME , PS.VALUE$ 
FROM PDB_SPFILE$ PS JOIN V$PDBS P ON PS.PDB_UID = P.CON_UID;

لیست پارامتر ها با شرایط توضیح داده شده در این بخش (طبیعتا با اعمال هر Patch set  امکان تغییر این لیست وجود دارد )

_ROLLBACK_SEGMENT_COUNT
_SMU_TIMEOUTES
_SMU_DEBUG_MODE
_UNDO_DEBUG_MODE
_HIGHTHRESHOLD_UNDORETENTION
_UNDO_AUTOTUNE
UNDO_RETENTION
_COLLECT_TEMPUNDO_STATS

تست failover دیتاگارد 19.12 و خطای ORA-16629

داشتم تست failover و حداکثر پایداری برای اپلیکیشن رو انجام میدادم به دو نکته برخورد کردم.

اولین نکته اینه که شما اگه میخواین تست failover انجام بدید اگه تو دیتابیس primary و standby مکانیزم flashback فعال باشه میتونید بدون راه اندازی کامل standby از اول این کار رو انجام بدید ولی اگه flashback فعال نباشه باید از اول به طور کامل standby جدید راه اندازی بشه. به این مکانیزم REINSTATE گفته میشه

نحوه انجام با broker

ابتدا فعال بودن flashback رو در primary و standby چک میکنیم:

SELECT FLASHBACK_ON FROM V$DATABASE;

برای چک کردن وضعیت بهتره یکباره از دستور show configuration استفاده بکنیم:

DGMGRL> show configuration
Configuration - g90
Protection Mode: MaxAvailability
 Members:
 tehrang - Primary database
 tehran - Physical standby database (disabled)
 ORA-16661: the standby database needs to be reinstated
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 91 seconds ago)

حالا باید دیتابیس fail شده رو که به مدار و حالت mount ببریم:

SQL> startup mount
ORACLE instance started.
Total System Global Area 4294964072 bytes
Fixed Size 9143144 bytes
Variable Size 2634022912 bytes
Database Buffers 1644167168 bytes
Redo Buffers 7630848 bytes
Database mounted.

ساخت سرویس جدید در سناریو دیتاگارد بدون زیرساخت Grid

تو سناریوی اوراکل دیتاگارد ما یک مدار دیتابیسی تشکیل میدیم که هر وقت سرور اصلی در سایت A از دسترس خارج شد اپلیکیشن با وقفه کوتاهی بتونه به سرور دوم در سایت B متصل بشه (تو سناریو حداکثر پایداری بهتره اپلیکیشن های ریپورت به دیتاگارد متصل نشن و برای سناریو اکتیو دیتاگارد یک دیتاگارد مجزا و مختص به ریپورت به صورت آبشاری راه اندازی بشه که بار روی سرور اصلی هم نباشه)

جهت انجام خودکار این سناریو به طوری که اپلیکیشن به یک سرویس جدا وصل بشه و وابسته به سرویس و IP در هر Instance در مواقع Failover و Switchover نباشه میتونید به شیوه زیر عمل کنید:

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

مقدار پیش فرض پیکربندی Page Size کش در دستگاه CLARiiON CX3‐40 برابر 8K است. این پیکربندی تاثیر مستقیم بر خواندن ترتیبی بلاک های کوچکتر از مقدار بلاک های cache را دارد. توصیه EMC این است که مقدار پیکربندی اندازه کش با بلاک سایزهای نوشته شده بر روی دیسک یکسان باشد. نتایج نشان می دهد این کار 226 درصد بهبود تعداد عملیات های I/O را در هر ثانیه ایجاد می کند.

عملیات خواندن ترتیبی I/O در هر ثانیه برای مقادیر 4K در خواندن ترتیبی با کش سایز متفاوت از بلاک سایز (نمودار بالاتر عملکرد بهتر را نشان می دهد)

شکل پایین نشان دهنده هزینه CPU برای هر عملیات I/O در تکنولوژی VMFS و RDM با 4K و 8K و مقدار 8K برای سایز کش است. ما از هزینه CPU در RDM با سایز کش 4K نیز تست گرفتیم و مقایسه این تکنولوژی ها رو باهم بر روی 4K و 8K سایز کش انجام دادیم. همانطور که مشاهده می کنید وقتی سایز کش با بلاک سایز یکی است هزینه CPU نزدیک 70 درصد در هر دو تکنولوژی VMFS و RDM بهبود یافته است.

هزینه عملیات CPU برای خواندن ترتیبی 4K با کش سایزهای متفاوت (نمودار پایینتر عملکرد بهتر را نشان می دهد).

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

نتیجه گیری

سرور Vmware ESX به شما 2 گزینه برای دسترسی و مدیریت دیسک پیشنهاد می دهد – VMFS و RDM. هر دو اینها از فایل سیستم کلاستر، اسامی کاربر پسند برای دیسک ها و فایل های اختصاص یافته شده پشتیبانی شده استفاده می کنند. هر دو VMFS و RDM از مهاجرت به وسیله vmotion پشتیبانی می کنند. این مطالعه مقایسه سرعت و کارایی را انجام داد و به غیر از تفاوت های ریز در سرعت و کارایی مورد دیگه ای پیدا نکرد.

برای تست لود دسترسی تصادفی بین VMFS و RDM در یک توان کاری I/O مشخص تفاوتی قابل محسوسی ندیدیم. در تست لود ترتیبی با سایز بلاک های I/O کوچک تکنولوژی RDM با افزایش کم توان کاری نسبت به VMFS برتری دارد. با این حال با افزایش سایز بلاک های I/O این گپ در توان کاری بین VMFS و RDM کمتر می گردد.

در تمام تست های لود با بلاک سایزهای متفاوت RDM هزینه مصرف CPU خیلی بهتری نسبت به VMFS دارد.

نتایج تست در این مطالعه نشان می دهد VMFS و RDM تقریبا یک لود کاری مشابه را در عملیات های I/O برای اکثر لودهای کاری ارائه می دهند. اما یک تفاوت در سرعت و کارایی I/O در لودهای کاری مواقعی است که CPU ماشین مجازی بر روی یک هاست با CPU کاملا رزرو شده اجرا گردد یا در این وضعیت بیافتد. البته این تفاوت فقط در اپلیکیشن هایی در دنیای واقعی قابل دیدن است که ماشین مجازی ها بخواهند از تمام ظرفیت منابع خود استفاده کنند. شما باید بسته به نوع سرویس انتخابی و SLA خود یکی از این 2 تکنولوژی را برای اپلیکیشن های Enterprise انتخاب کنید.

به هر حال چند نمونه براتون مثال می زنیم که بدونید چه اپلیکیشن هایی باید از RDM استفاده کنند:

• اپلیکیشن های backup که به طور ترتیبی دیتا رو با یک بلاک سایز مشخص از دیسک می خوانند
• اپلیکیشن های پایگاه داده که بار کاری بالایی بر روی دیتا دارند و نیازمند سرعت و کارایی زیاد هستند

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

سخت افزارهای مورد استفاده

• ذخیره ساز: CLARiiON CX3‐40 (4Gbps)
• حافظه: 4 گیگ برای هر پردازنده ذخیره ساز
• دیسک های مورد استفاده: 25 دیسک برند segate 146 گیگ با سرعت 15K RPM با RAID 0
• HBA برند QLA 2460 4Gbps

نرم افزار

• مجازی ساز: ESX Server 3.5 (build 64607)

پیکربندی سیستم عامل مهمان

• سیستم عامل: ویندوز سرور 2003 سرویس پک 2 معماری 32 بیتی با 512 مگابایت رم و 1 سی پی یو سوکت
• دیسک تست: 20 گیگابایت دیسک فرمت نشده

پیکربندی ذخیره ساز

• کش خواندن: 1 گیگابایت برای هر پردازنده ذخیره ساز
• کش نوشتن: 1.9 گیگابایت
• RAID-0 گروه 1: 10 دیسک (10 گیگابایت LUN)
• RAID-0 گروه 2: 15 دیسک (10 گیگابایت LUN)
• ظرفیت MetaLUN: 20 گیگابایت

پیکربندی Iometer

• تعداد عملیات های I/O ورودی و خروجی: 64
• زمان اجرا: 5 دقیقه
• زمان افزایش شیب: 60 ثانیه
• تعداد workerهای خودکار: 1

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

تست لود تصادفی

در این تست لود تصادفی برای تکنولوژی VMFS و RDM به جهت دسترسی به سرعت و کارایی بالا مد نظر است:

لود تصادفی ادغامی (50 درصد تست دسترسی خواندن و 50 درصد تست دسترسی نوشتن) (بالا بودن نمودار عملکرد بهتر را نشان می دهد)

دسترسی تصادفی خواندن برای عملیات I/O در هر ثانیه (بالا بودن نمودار عملکرد بهتر را نشان می دهد)

دسترسی تصادفی نوشتن برای عملیات I/O در هر ثانیه (بالا بودن نمودار عملکرد بهتر را نشان می دهد)

تست لود ترتیبی

برای خواندن ترتیبی با بلاک سایز 4K ما تغییراتی را در مقدار بلاک سایز کش در سخت افزار خود (CLARiiON CX3‐40) به مقدار 4k انجام داده ایم. البته برای باقی تست ها از همان مقدار پیش فرض 8K در بلاک سایز کش استفاده کرده ایم.

در سرور ESX 3.5 سرعت و کارایی لود ترتیبی تکنولوژی VMFS خیلی نزدیک به RDM برای تمام بلاک سایزهای تولیدی به جز 4K بود.اغلب اپلیکیشن ها با لود ترتیبی از بلاک سایزهایی با مقادیر بیشتر از 4K استفاده می کنند. هر 2 تکنولوژی های VMFS و RDM تقریبا عملکردی مشابه در سرعت و کارایی داشتند.

هر 2 تکنولوژی های VMFS و RDM توان کاری (throughput) بالایی را از خود نشان دادن به جز مواردی که باری نزدیک 300 مگابایت در ثانیه در حال اجرا بود.

تست لود خواندن ترتیبی عملیاتهای I/O بر حسب ثانیه (بالا بودن نمودار عملکرد بهتر را نشان می دهد)

تست لود نوشتن ترتیبی عملیات های I/O بر حسب ثانیه (بالا بودن نمودار عملکرد بهتر را نشان می دهد)

جداول پایین میزان توان کاری (throughput) بر حسب ثانیه را برای VMFS و RDM مکتوب کرده اند. میازن توان کاری(throughput) بر حسب (عملیات های IO * سایز دیتا) با نمایش مقدارهای متناظر است:

جدول میزان توان کاری برای لود تصادفی بر حسب مگابایت بر ثانیه

Random Write			Random Read			Random Mix
RDM (P)	RDM (V)	VMFS	RDM (P)	RDM (V)	VMFS	RDM (P)	RDM (V)	VMFS	Data Size (KB)
45.87	46.1	46.38	23.27	23.27	23.41	31.15	30.98	30.96	4
88.74	89.22	90.24	44.35	44.43	44.67	58.68	58.68	58.8	8
159.42	158.25	161.2	80.58	80.72	80.14	105.09	106.03	105.22	16
242.05	241.12	241.4	138.11	138.53	135.91	176.69	176.1	173.72	32
310.15	311.13	309.6	214.59	215.49	215.1	263.98	262.92	256.14	64

جدول میزان توان کاری برای لود کاری ترتیبی

Sequential Write			Sequential Read
RDM (P)	RDM (V)	VMFS	RDM (P)	RDM (V)	VMFS	Data Size (KB)
93.36	93.8	93.76	153	142.13	137.21	4
187.84	188.45	188.45	188.56	284.41	272.61	8
278.91	281.17	281.17	280.95	338.75	341.08	16
352.89	354.86	354.86	352.17	364.23	363.86	32
386.81	385.36	384.02	377.09	377.6	377.35	64

هزینه CPU

هزینه CPU براساس تعداد سایکل های CPU برای انجام یک عمل واحد I/O برای استفاده از توان کاری (به بایت) محاسبه میگردد. ما محاسبه سایکل های CPU را براساس استفاده ماشین مجازی از CPU فیزیکی برای اجرای تست لود کاری گرفته ایم. ما برای محاسبه لود کاری سربار مجازی سازی را نیز جهت مجازی سازی ماشینهای متفاوت براساس پراسس های سرور ESX حساب کرده ایم. توان CPU براساس MHz و تمام coreهای درگیر در سیستم رنک بندی میگردند. در این مطالعه معیارهای هزینه CPU براساس تعداد سایکل های CPU بر حسب واحدهای عملیاتی I/O در هر ثانیه دیده شده است.

نتیجه هزینه CPU عادی برای لودهای کاری متفاوت در شکل های زیر نمایش داده شده است. ما هزینه CPU را برای RDM (مپ کردن فیزیکی دستگاه ذخیره ساز به ماشین مجازی) برای هر تست لود کاری با مقایسه آن با تکنولوژی VMFS مشخص کرده ایم.

در تست لود تصادفی هزینه CPU تکنولوژی VMFS حدود 5 درصد بیشتر از هزینه CPU در تکنولوژی RDM بوده است.

همچنین در تست لود ترتیبی هزینه CPU تکنولوژی VMFS حدود 8 درصد بیشتر از هزینه CPU در تکنولوژی RDM بوده است.

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

هزینه CPU عادی برای دسترسی تصادفی به صورت خواندن/نوشتن در انواع بلاک سایزها (نمودار کم بهتر است)

هزینه CPU عادی برای دسترسی تصادفی به صورت خواندن در انواع بلاک سایز ها (نمودار کم بهتر است)

هزینه CPU عادی برای دسترسی تصادفی فقط نوشتن در انواع بلاک سایزها (نمودار کم بهتر است)

هزینه CPU عادی برای دسترسی تصادفی فقط خواندن در انواع بلاک سایزها (نمودار کم بهتر است)

هزینه CPU عادی برای دسترسی تصادفی فقط نوشتن در انواع بلاک سایزها (نمودار کم بهتر است)

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

خلاصه تست اجرایی توسط شرکت Vmware

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

• برای خواندن، نوشتن تصادفی (random) هر 2 تکنولوژی تقریبا نتایج مشابهی در عملیات های IO در ثانیه داشتند
• در خواندن، نوشتن ترتیبی (sequential) سرعت VMFS خیلی نزدیک به RDM بود (به غیر از مواردی که بلاک سایزها 4k در نظر گرفته شده بود). هر 2 تکنولوژی ها توان عملیاتی (throughput) بالایی رو داشتند به غیر از مورد نوشتن 300 مگابایت در ثانیه که VMFS به خوبی در آن عمل نکرد.
• در خواندن و نوشتن تصادفی (random) فایل سیستم VMFS نیازمند 5 درصد CPU بیشتر در هر cycle عملیات IO در مقایسه با RDM بود.
• در خواندن و نوشتن ترتیبی (sequential) فایل سیستم VMFS نیازمند 8 درصد CPU بیشتر در هر cycle عملیات IO در مقایسه با RDM بود.

جهت مطالعه کامل سناریو تست به داکیومنت زیر مراجعه گردد:

Performance Characterization of VMFS and RDM Using a SAN: ESX Server 3.5 (vmware.com)

محیط تست

مطالعه در محیط تست برای مقایسه VMFS و RDM در ESX Server 3.5 انجام شده است (آخرین مستند ارائه شده توسط شرکت VMware تا زمان نگارش مطلب) تست بر روی ماشین مجازی با یک سوکت با استفاده از ویندوز سرور 2003 نسخه EE SP2 به عنوان سیستم عامل ماشین مجازی انجام شده است. سرور ESX بر روی دیسک های لوکال SCSI پیکربندی شده است. 2 دیسک مجازی به ماشین مجازی متصل شده است یکی برای سیستم عامل و یکی برای محیط تست که بر روی آن عملیات های IO صورت می گیرد. لود ایجاد شده با استفاده از ابزار Iometer بوده که یک ابزار خیلی محبوب برای سنجش سرعت و کارایی IO سخت افزار است. لیست سخت افزارها و نرم افزارهای مورد استفاده در انتها آورده شده است.

برای تمام لود ها به غیر از تست لود 4K ترتیبی خواندن از کش پیشفرض با page size برابر 8K در لایه سخت افزار و raid controller استفاده شده است. در هر حال تست لود ترتیبی خواندن 4K با کش پیش فرض سرعت و کارایی خیلی پایینی هم در VMFS و هم در RDM دارد. شرکت EMC پیشنهاد می کند مقدار کش page size در ذخیره ساز (لایه کنترلر) برابر مقدا block size اپلیکیشن باشد (در این جا برای تست 4K باید کش را برابر 4K قرار دهیم.)

از این رو برای تست لود ترتیبی خواندن 4K با مقدار page size کش را برابر 4K میگذاریم. برای دیدن مقایسه در زمانی که مقدار کش برابر 4K و وقتی برابر 8K قرار داده شده است نمودارهای زیر را ملاحظه کنید.

مقایسه تست لود ترتیبی خواندن در هر ثانیه در زمان قراردادن مقدار 4K برای اپلیکیشن و قراردادن page size برابر مقدار پیش فرض و مقدار 4K (بالا بودن نمودار کارایی بهتری را نشان می دهد)

هزینه استفاده از CPU برای تست ترتیبی خواندن بلاک های 4K با بلاک های کش متفاوت (پایین بودن نمودار کارایی بیشتری را نشان می دهد)

لایه دیسک

 در این مطالعه پیکربندی لایه دیسک و نحوه قرار گیری آن ها به دقت انتخاب شده است. ما سرور را به صورت مستقیم با فیبر نوری و HBA به یک دستگاه SAN با مدل CLARiiON CX3‐40 متصل کردیم. ما 2 گروه RAID 0 بر روی SAN ایجاد کردیم یکی دارای 15 دیسک و دیگری دارای 10 دیسک. ما یک LUN با حجم 10 GB بر روی هر گروه RAID ایجاد کردیم. بعد یک metaLUN با حجم 20GB با استفاده از این 2 LUN 10GB ای پیکربندی شده است.

ما از این metaLUN جهت دیسک تست استفاده می کنیم. (metaLUN امکان بهم پیوستن (Aggregate) جهت افزایش سایز و سرعت را نسبت به LUN اصلی، فراهم می آورد.) دیسک های استفاده شده برای این تست تنها برای این تست لود I/O مورد استفاده قرار گرفته اند. ما یک دیسک مجازی بر روی دیسک های تست ایجاد کردیم و اون رو برای ماشین مجازی ویندوز مورد استفاده قرار دادیم. به دلیل استفاده از زیرساخت ESX و ایجاد datastore ماشین مجازی از نوع و نحوه چینش این دیسک ها اطلاعی ندارد و اون رو به عنوان یک دیسک فیزیکی شناسایی می کند.

شکل زیر پیکربندی دیسک مورد استفاده را نمایش می دهد. در تست VMFS ما از یک دیسک مجازی با فرمت VMDK برای ذخیره سازی به عنوان پارتیشن VMFS به عنوان دیسک تست استفاده کردیم. ولی در تست RDM ما یک فایل پیکربندی RDM برای ماشین مجازی ایجاد کردیم و مپ این فایل را به دیسک تست انجام دادیم. ما پیکربندی دیسک مجازی محیط تست رو با یک LSI SCSI HBA انجام دادیم.

خوشبختانه ابزار Iometer قابلیت این را دارد که بدون ساخت پارتشین و فایل سیستم در سیست عامل بر روی یک raw دیسک تست خواندن، نوشتن را نیز انجام دهد. پس ما بدون استفاده از فایل سیستم و فرمت این فضاها تست لود کار را انجام دادیم.

پیکربندی

ما پیکربندی سیستم عامل مهمان را با استفاده از درایور و کنترلر LSI Logic SCSI انجام دادیم.در حالت استفاده از VMFS ما یک دیسک مجازی به صورت Thick Provisioned Eager Zeroed که به عنوان راهکار برتر به جهت استفاده از فضا برای دیتا در VMFS است ساختیم.

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

ما در هر test case قبل از شروع به انجام آزمایش با استفاده از برنامه های خط فرمان تمام مقادیر دیسک مجازی را 0 کردیم. (VMkfstools با آپشن w)

مشخصات لود I/O

اپلیکیشن های سازمانی (Enterprise) به طور معمول و عمومی لود I/O با پترن های متفاوت تولید می کنند. پس ندازه blockهای انتقال داده شده در سرور هاست اپلیکیشن و ذخیره ساز ممکن است به طور متناوب تغییر یابد. نحوه طراحی و شیوه چینش دیسک ها و لایه فایل سیستم برای دسترسی به سرعت و کارایی بالا در لودهای کاری بسیار بسیار مهم است.

اپلیکیشن های کمی هستند که یک پترن دسترسی مشخص برای سایز block ها دارند. یک مثال برنامه های بک آپ هستند که از یک پترن برای خواندن ترتیبی بلاک ها استفاده می کنند. دیتابیس های OLTP برخلاف این اپلیکیشنها اکثرا بسیار random کار میکنند. به صورت طبیعی اپلیکیشنها بر روزی اندازه blockهای در حال انتقال تاثیر می گذارند.

Test Caseها

در این مطالعه، مشخصات لود سرعت و کارایی برای 2 تکنولوژی VMFS و RDM برای یک رنج از بلاک ها با پترن های متفاوت را مشخص می کنیم. سایز بلاک های انتقال داده شده بین 4KB, 8KB, 16KB, 32KB و 64KB انتخاب شده اند. پترن دسترسی مشخص شده توسط ما به صورت تصادفی عملیات خواندن و نوشتن و به صورت ترتیبی عملیات خواندن و نوشتن یا ترکیبی از خواندن و نوشتن را انجام می دهد.

ایجاد لود آزمایشی

ما از Iometer که یک benchmarking tool معروف و محبوب است و به طور گسترده برای سخت افزارهای Intel جهت تست های سرعت و کارایی(performance) استفاده می گردد، برای ایجاد لود آزمایشی استفاده کردیم. Iometer توانایی تهیه و اجرای انواع تست های طراحی شده I/O را دارد. به این دلیل که ما طراحی یک تست مشخص برای سنجش سرعت و کارایی دیسک ماشین مجازی در یک دیوایس خام (raw) و VMFS را داریم از شبیه ساز لود basix برای تست های زیر استفاده می کنیم:

• ابزار Iometer با مقادیر زیر جهت تست پیکربندی شده است:
  • انتقال بلاک ها با سایز: 4KB, 8KB, 16KB, 32KB و 64KB
  • درصد توزیع تصادفی یا ترتیبی برای هر سایز بلاک از 0 درصد تا 100 درصد توزیع
  • درصد توزیع میزان خواندن و نوشتن برای هر درخواست I/O از 0 درصد تا 100 درصد توزیع و یا حتی 50 درصد توزیع برای خواندن و 50 درصد توزیع برای نوشتن

 

• پارامترهای زیر برای تمام حالات test case ثابت است:
  • تعداد عملیات های I/O ورودی و خروجی: 64
  • زمان اجرا: 5 دقیقه
  • زمان افزایش شیب: 60 ثانیه
  • تعداد workerهای خودکار: 1

نتایج تست سرعت و کارایی

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

معیارها

معیارهای مورد استفاده برای مقایسه بین VMFS و RDM برای I/O براساس تعداد عملیات ها در هر ثانیه، مقدار توان عملیاتی (برحسب MB بر ثانیه)، و هزینه CPU بر حسب MHz بر ثانیه است.

در این مطالعه ما گزارش معیارهای I/O را توسط معیارهای گفته شده با ابزار Iometer انجام دایدم و مقایسه را در هر بخش برای VMFS و RDM انجام دادیم. این معیارها با هزینه CPU برای هر واحد I/O با استفاده از فرمول زیر محاسبه شده اند:

تمام وضعیت های I/O و CPU جمع آوری شده توسط 2 نرم افزار Iometer و esxtop بوده اند:

• Iometer – جمع آوری عملیات های I/O در هر ثانیه و مقدار توان عملیاتی در MB بر ثانیه
• Esxtop – جمع آوری میانگین مصرف CPU از طریق محاسبه میزان CPU استفاده شده در ماشین مجازی در CPU فیزیکی

سرعت و کارایی

این بخش مقایسه سرعت و کارایی با مشخصات توضیح داده شده برای Test case را مورد ارزیابی قرار می دهد.