به حداکثر رساندن عملکرد ذخيره سازي

روزي يک سرويس گيرنده با ما تماس گرفت تا به نحوي خريدن يک SAN هزار دلاري را جهت دسترسي 3000تا4000 کاربر همزمان به بيش از 150گيگابايت اطلاعات را توجيه کند، اين سرويس گيرنده با مشکلات اجرايي مواجه شده بود. فروشندگان قطعات سخت افزاري يک SAN جديد را پيشنهاد کرده بودند تا تنگناي I/O را کنترل نمايد و نزديک بود که ما راه حل پيشنهادي را بپذيريم. به هر حال، يک ارز يابي از حجم کار سرويس گيرنده و همچنين محيط فعلي مشخص کرد که با وجود ديسک ها، کنترل کننده هاي RAID و سخت افزارهاي ديگر که 35000 دلار ارزش دارند، استفاده از آن ها به شکل کارامدي صورت نمي گيرد. ما تنها با استفاده از سخت افزار موجود، عملکرد را افزايش داديم و نياز به يک SAN گرانقيمت را بر طرف نموديم. با استفاده از سرويس استراتژي هاي زير که ما براي کمک به سرويس گيرنده مان استفاده کرديم، مي توانيد عملکرد را تقويت نمائيد و خود را از صرف هزينه براي يک سخت افزار خاص نجات دهيد. ذخيره سازي به يک اندازه نيست: با توجه به اينکه درايوهاي ديسک همچنان ارزان تر مي شوند، اما هزينه کردن براي تعداد زيادي درايو سخت آخرين مدل (high-end) و کنترل کننده هاي RAID، هنوز يک نگراني عمده براي بسياري سازمان ها محسوب مي شود. بعلاوه، برخي از انواع حافظه ها و سخت افزارها، در مقايسه با ساير تجهيزات، گزينه هاي بهتري براي کار با SQL Server هستند. جدول1، برخي از انواع معمولي آرايه هاي RAID را ليست مي کند، جدول2، روش هاي معمولي ارتباط حافظه با کامپيوتر را ليست مي کند و جدول3، سرعت هاي معمولي چرخش ديسک را ليست مي کند. هر جدول به شما مي گويد که گزينه هاي مختلف سخت افزاري تا چه حدي براي SQL Server خوب مناسب هستند. جدول ها مشخص مي کنند که تمام حافظه ها به يک اندازه ساخته نمي شوند، که البته خوب است، چرا که نيازمندي هاي اجرايي از يک موضع به موضع ديگر متفاوت است. از اين رو، مي خواهيم با شناسايي آن چه که آن را "ديسک برتر" (premium disk) مي ناميم به سناريوها ي بهينه سازي

نوع	موافقین	مخالفین	توصیه
RAID 0 نواره ای کردن (Striping )	بهترین عملکرد. خواندن ها و نوشتن ها به طور یکسان در سراسر تمام دیسک ها در آرایه تقسیم می شوند وموجب سریع تر شدن آنها می گردد.	فاقد افزونگی: از بین رفتن یک درایو موجب از دست رفتن کل داده ها می گردد.	به دلیل احتمال از دست رفتن داده ها . برای استفاده در محیط های SQL Server توصیه نمی شود.
RAID 1 قرینه سازی (Mirroting )	تحمل خرابی (fault- tolerance مطمئن، چرا که داده درتمام دیسک ها در آرایه نوشته می شوند. خواندن ها را می توان در سراسر دیسک ها در آرایه تقسیم	نوشتن ها نسبت به سرعت یک دیسک کند می شوند، چرا که تمام نوشتن ها درهر دیسک نوشته می شوند.	به خوبی برای فایل های داده ای کم – تقاضا کار می کند. برای فایل های ثبت وقایع، فوق العاده است.
RAID 5 نواره ای کردن با توازون (Striping with Parity )	افزونگی فوق العاده: یک درایو ممکن است خراب شود، بدون آنکه کل آرایه     فتد. عملکرد صحیح ودرست خواندن. بسیار با صرفه	راهکارهای RAID 5 ، برای به اجرا درآوردن افزونگی، مستلزم دو خواندن و دو نوشتن به ازای هر عمل منطقی نوشتن است، واین موجب می شود تا نوشتن بسیار گرانتر شود.	راه کاری به صرفه برای کارهایی با عملکرد بالا که نوشته های زیادی انجام نمی دهند. در سیستم هایی که نوشتن ها بیش از 10 درصد دهند. استفاده نشود.
RAID 1+0 قرینه سازی + نواره ای کردن +(Mirroring Striping )	قدرت RAID 0  و RAID 1 را ادغام می کند تا محافظت در برابر خروجی وعملکرد فوق العاده را ارائه دهد.	به دیسک ها وکنترل  کننده های مدل بالای بسیار زیادی نیاز دارد. یکی از گرانترین راهکارهای RAID است.	برای تمام نیازهای بانک اطلاعاتی با عملکرد- بالا، فوق العاده است . دربرخی موارد کمی افراط درمورد فایل های ثبت وقایع

جدول 1:انواع متعارف RAID
  نوع-موافقين-مخالفين-توصيه- RAID 0 نواره اي کردن (Striping)- بهترين عملکرد. خواندن ها و نوشتن ها به طور يکسان در سراسر تمام ديسک ها در آرايه تقسيم مي شوند و موجب سريع تر شدن آن ها مي گردد.-فاقد افزونگي. از بين يک درايو موجب از دست رفتن کل داده ها مي گردد. - به دليل احتمال از دست رفتن داده ها، براي استفاده در محيط هاي SQL Server توصيه نمي شود. - RAID 1 قرينه سازي (Mirroring) - تحمل خرابي (fault-tolerance) مطمئن، چرا که داده در تمام ديسک ها در آرايه نوشته مي شوند. خواندن ها را مي توان در سراسر ديسک ها در آرايه تقسيم - نوشتن ها نسبت به سرعت يک ديسک کُند مي شوند، چرا که تمام نوشتن ها در هر ديسک نوشته مي شوند.- به خوبي براي فايل ها داده اي کم تقاضا کار مي کند. براي فايل هاي مثبت وقايع، فوق العاده است. - RAID 5 نواره اي کردن با توان (Striping with parity) - افزونگي فوق العاده: يک درايو ممکن است خراب شود، بدون آن که کل آرايه فتد. عملکرد صحيح و درست خواندن. بسيار با صرفه. - راه کارهاي RAID 5 ، براي به اجرا در آوردن افزونگي، مستلزم دو خواندن و دو نوشتن به ازاي هر عمل منطقي نوشتن است، و اين موجب مي شود تا نوشتن ها بسيار گران تر شود. - راه کاري به صرفه براي کارهايي با عملکرد بالا که نوشتن هاي زيادي انجام نمي دهند. در سيستم هايي که نوشتن ها بيش از 10 درصد دهند، استفاده نشود. - RAID 1+0 قرينه سازي+نواره اي کردن (Mirroring + Striping) - قدرت RAID 0 و RAID 1 را ادغام مي کند تا محافظت در برابر خرابي و عملکرد فوق العاده را ارائه دهد. - به ديسک ها و کنترل کننده هاي مدل بالاي بسيار زيادي نياز دارد. يکي از گران ترين راهکارهاي RAID است. - براي تمام نيازهاي بانک اطلاعاتي با عملکرد بالا، فوق العاده است. در برخي موارد کمي افراط در مورد فايل هاي ثبت وقايع ديسک بپردازيم، که بهترين گزينه حافظه اجرايي موجود مي باشد. مثلاً، در پيکربندي هاي ديسک که در شکل 1آمده، ديسک برتر در Server1، مشخصاً حجم 220 گيگابايت است در حالي که در Server2 حجم 640 گيگابايت مي باشد. کليد شناسايي ديسک برتر اين حقيقت است که تقريباً تمام استقرارهاي SQL Server حداقل به دو نوع ديسک دسترسي دارند. قابليت هاي ديسک برتر بسيار متفاوت است، اما شما مي توانيد معمولاً دوتا از آن ها را برشماريد. اولاً، ديسک هاي برتر سريع، کوچک هستند، چرا که درايو هايي که عملکرد بالايي دارند معمولاً ظرفيت را قرباني سرعت مي کنند. دوماً اينکه، در مقايسه با ديسک هاي غير برتر، تعداد ديسک هاي برتر موجود کمتر است و اگر سيستم لحظه اي فعال باشد، ظرفيت ديسک برتر کمتر از آن چه مي خواهيد است. کليد رسيدن به تعادلي ميان عملکرد و قيمت، بهينه سازي عملکرد ديسک برتر است، و آن هم زماني است که بسياري از کارها را تا جاي ممکن، به ديسک غير برتر off-load مي کنيم.

فايل هاي داده اي چندگانه:
 

نکته کليدي بهينه عملکرد ديسک برتر، تحت کنترل گرفتن و استفاده از کنترل کننده ها و ديسک ها به قدر کافيست. ارتباط منبع مي تواند در جايي که نيازمندي هاي ذخيره سازي به طور يکسان در سراسر تمام ديسک ها پخش نمي شوند، منجر به hotspots ها شود، بنابراين اجتناب از ارتباط، روشي است که خاطر نشان مي کند سيستم هاي ذخيره سازي شما به درستي استفاده شده اند. در مورد بانک هاي اطلاعاتي بزرگ که بسيار مورد استفاده قرار مي گيرند، مايکروسافت پيشنهاد مي کند که به ازاي هر file group براي هر CPU در يک سرور، بين 0/25 و 1 فايل داده اي استفاده کنيد. با اين روش، SQL Server به جاي آن که اجراي پرس و جو را مجبور کند تا در يک thread منتظر بماند نا داده ها را از ديسک بيرون بکشد، مي تواند چندين thread توليد کند تا همزمان نيازمندي هاي I/O را براي پرس وجوهايي که مي تواند به طور موازي پردازش کند، بر طرف سازد. حتي با کنترل کننده هاي گران قيمت RAID و ديسک هاي 15,000rpm، اگر تنها يک محور يا ديسک داريد که حجم کار شما را اداره مي کند، ممکن است مزاياي اجرايي را که SQL Server مي تواند با استفاده از thread هايI/O به شکل کارآمدي ارائه دهد تا نيازمندي هاي پرس و جوهاي پيچيده و بزرگ را برآورده سازد، از دست بدهيد. حتي اگر فضاي زياد ديسک با عملکرد بالا داريد، ديسک بسيار کندتر از RAM يا CPU است، بنابراين اگر اين فضا به شکل کارآمدي مورد استفاده قرار نگيرد، داراي پتانسيل فوق العاده اي براي بي ثبات کردن حجم کارهاي شماست. صرفاً، افزودن چندين فايل داده اي به بانک هاي اطلاعاتي بزرگ و پر مصرف مي تواند به SQL Server کمک کند تا به اجراي موازي بزرگتر و زمان هاي پشتيبان گيري کوتاه تر برسد. اما توزيع هوشمندانه داده ها در سراسر فايل ها منجر به بهترين نتايج مي گردد. مثلاً ، اگر جدولي داريد که مکرراً هدف بسيار از پرس و جوهاي گسترده قرار مي گيرد، گسترش آن جدول در سراسر چندين فايل مي تواند به خواندن هاي متوالي اجازه دهد تا به جاي مجبور کردن اجرا به بيرون کشيدن همه چيز از يک فايل، نيازهاي پرس و جو را برآورده سازند. اثر جداسازي فايل ها زماني بيشتر عنوان مي شود که شما بتوانيد اين فايل ها را در آرايه هاي مختلف ديسک قرار دهيد. بعلاوه، خوب است که در جدول هاي بزرگ و پرمصرف، شاخص ها را در يک file group اختصاصي تقسيم کرد. تقسيم کردن شاخص ها به اين روش موجب پردازش موازي شاخص و داده هاي جدول در پرس و جوهاي پيچيده تر مي گردد که مستلزم فيلترها و عمل هاي نشانه گذاري بيشتري هستند.

قرار دادن فايل ثبت وقايع:
 

برخلاف فايل هاي داده اي، فايل هاي ثبت وقايع از گسترش يافتن ميان چندين فايل هيچ نفعي نمي برند، چرا که SQL Server به صورت پي در پي داده ها فايل ثبت وقايع را مي نويسد. اما شما بايد هر زمان که امکان پذير بود، فايل هاي ثبت وقايع را در آرايه هاي اختصاصي ديسک قرار دهيد؛ چرا که آن ها مي توانند در زمان ساخته شدن بسياري از به روز رساني ها، حجم زياديI/O توليد کنند. استفاده از آرايه هاي اختصاصي ديسک کمک مي کند تا فعاليت نوشتن فايل ثبت وقايع از فعاليت I/O پرس و جوها واصلاحات داده ها در بقيه بانک اطلاعاتي، جدا شود. آرايه هاي 5 RAID مستلزم دو خواندن و نوشتن فيزيکي بازاي هر نوشتن منطقي هستند، بنابراين معمولاً بايد از استفاده از آرايه هاي RAID 5 براي فايل هاي ثبت وقايع پرهيز کرد. آرايه هاي RAID 1 +. بهترين گزينه هستند، اما آرايه هاي RAID 1 با ديسک هاي سريع مي توانند حجم هاي کاري بسيار سنگين را زمانيکه منحصراً براي فايل هاي ثبت وقايع استفاده مي شوند، کنترل نمايند.

پراکندگي ذهن و File Factor :
 

در جدول هاي بزرگ و شاخص هايي که شاهد به روز رساني ها و حذف کردن هاي بسيار هستند، پراکندگي مي تواند به راحتي فضاهاي بي مصرفي را به وجود آورد و به عمل هاي I/O آسيب برساند، چرا که SQL Server، جدول و داده هاي شاخص را در حافظه صفحه بندي مي کند. پراکندگي اغلب مي تواند بسيار بد شود، و در جدول هايي که بسيار مورد پرس و جو واقع مي شوند، منجر به تاخير قابل ملاحظه اي در زمان پاسخگويي به کاربران نهايي مي گردد. بسياري از کارشناسان، از جمله برخي از کارشناسان، در مايکروسافت مرتباً توصيه مي کنند که با استفاده از دستور CREATE INDEX يا دستور ALTER INDEX ، شاخص ها را باز سازي و يکپارچه سازي نمائيد و تنظيم fille-factor را ميزان کنيد تا به اين ترتيب با تاخير و پراکندگي بيش از حد مبارزه نمايند .ميزان سازي دقيق تنظيم fille-factor در جدول هايي که بسيار پرس و جو نوشته مي شوند، مي تواند دشوار باشد. پراکندگي بسيار زياد منجر به عمل هاي خواندن بيهوده مي گردد و فضاي خالي بسيار کوچک مي تواند سرعت درج را به شدت تحت تاثير قرار دهد. هيچ قاعده کلي و يا روشي که مناسب همه باشد، وجود ندارد و حتي بهترين راه حل، نگراني هاي زيست محيطي و الگوهاي مصرفي را به دنبال دارد. بهترين روش براي رسيدن به تنظيم fille-factor، جمع آوري و تجزيه و تحليل مرتب متريک هاي عملکرد، و سپس انجام تغييرات کوچک، نظارت بر تاثير آن ها و تنظيم مجدد در صورت نياز است. اين روش نياز به اندکي سعي و تلاش دارد. اما اگر مي توانيد تنظيمات بهينه fille-factor را براي جدول هاي کليدي خود برقرار سازيد و از زمان هاي غير-پيک براي باز سازي جدول ها و شاخص هاي خود استفاده نمائيد، مي توانيد در مواردي که پاي جدول هاي بزرگ در ميان است، عملکرد را به شکل چشمگيري تقويت نمائيد. تا وقتيکه اندکي زمان بيکاري در اختيار داريد، دليلي وجود ندارد که نتوانيد شاخص ها را شبانه بسازيد.

فضاي خالي موجود:
 

گرچه افزايش هر اونس ديسک برتر يک هدف ارزشمند است، اما مراقب فضاي خالي موجود باشيد. اگر ديسک هاي شما بايد مدت زيادي کار کنند تا فضاي خالي موجود در درايو بيابند، خواهيد ديد عملکرد به طور چشمگيري پايين مي آيد. لحظه اي که اين اشباع رخ مي دهد، در هر ديسک متفاوت است و بستگي به عوامل مختلفي از جمله مشخصات عملکرد خام درايوها و کنترل کننده هاي مربوطه آن ها دارد، اما يک قانون کلي خوب، حفظ حداقل 15تا25 درصد فضاي خالي در درايو شماست. يک روش فوق العاده براي خالي کردن ديسک برتر، offload کردن همه بلکه اکثر بانک هاي اطلاعاتي مهم به حافظه ي ارزانقيمت تر است. با قرار دادن يک چنين بانک هاي اطلاعاتي در SAN يا حافظه ي ارزان قيمت تر ديگر مي توانيد ديسک برتر را براي بانک هاي اطلاعاتي يا عمل هاي مهم ماموريتي خالي نمايي. اين مسئله به خصوص در مورد کارخانه هاي کوچکي صادق است که بانک هاي اطلاعاتي توسعه و مرحله بندي آن ها معمولاً در همان سخت افزاري مستقر هستند که بانک هاي اطلاعاتي توليد مستقر هستند. پارتيشن بندي مي تواند يک ابزار قدرتمند براي offload کردن داده ها باشد و طرح هاي پارتيشن بندي SQL Server 2005 کار offload کردن داده ها را آسان مي سازد. file group هاي خود را بسازيد و فايل هاي خود را بيافزائيد، فايل هايي را که کمتر از آن ها استفاده مي کنيد، در ديسک ارزان تر قرار دهيد. طرح پارتيشن خود را بسازي، SQL Server بقيه کارها را انجام مي دهد.

مديريت هوشمندانه ي پشتيبان گيري ها:
 

پشتيبان گيري يک شمشير دولبه است. شما مي خواهيد از بانکي اطلاعاتي بزرگ در ديسک برتر پشتيبان بگيرد تا توان عملياتي را به حداکثر برسانيد. مشکل اينجاست که وقتي پشتيبان گيري ها به اتمام مي رسد، تنها چيزي که آن ها نياز دارند تعداد زيادي ديسک است، و آن ها مي توانند سريعاً ديسک برتر را ببلعند. از آنجائيکه اکثر پشتيبان گيري هاي کامل در ساعت هاي غير پيک انجام مي شوند، معمولاً پيشنهاد مي کنيم زمانيکه فضاي ديسک برتر کافي نيست، پشتيبان ها را در ديسک غير-برتر قراردهيد. اين روش به پشتيبان ها اجازه مي دهد تا تنها فضاي موجود در ديسک هاي غير برتر را اشغال کنند و زمانيکه اين کار در ساعت هاي غير پيک انجام مي شود، سربار اجرايي مربوط به استفاده از ديسک غير-برتر، تاثير زياد ندارد. گزينه ديگر براي پشتيبان گيري ها، به کارگيري ابزاري براي فشرده سازي پشتيبان مي باشد. اين ها معمولاً ارزان تر از ديسک برتر اضافي هستند و زمان بازيابي را کاهش مي دهند. پشتيبان گيري هاي off-box در يک ISCSI SAN يا يک اشتراک فايل شبکه، نيز مي توانند گزينه هاي خوبي باشند. اما يک قانون کلي خوب اين است که هميشه پشتيبان گيري هاي کامل يک يا دو روز را از جمله، پشتيبان گيري ها و ثبت وقايع کامل را در حافظه اي که به راحتي قابل دسترس است، نگه داريد. در مواقع بحراني اين کار بسيار مفيد واقع مي شود.

مديريت کارآمد فايل ثبت وقايع:
 

بسياري از محيط هاي SQL Server تنها داراي يک کنترل کننده RAID و يک آرايه RAID هستند، که فايل هاي داده اي و ثبت وقايع بايد به اشتراک بگذارند. در نتيجه، فايل هاي ثبت وقايع سر از ديسک برتر در مي آورند و مي توانند مقدار زيادي ديسک با عملکرد بالا را که نيازي به آن ندارند، ببلعند. مثلاً اگر ديسک يک بانک اطلاعاتي 100GB داريد که هر روزه شاهد 12GB فعاليت ثبت شده است، احتمالاً يک فايل ثبت وقايع حدود 25GB مي خواهيد که براي اداره کردن لود و account روزانه براي جرقه هاي (spike) موجود در فعاليت کافيست. در عوض 25GB از ديسک برتر مصرف مي شود، اما اطلاعات فايل ثبت وقايع در حافظه ارزان تر، مانند آرايه RAID 1 کاملاً ايمن است. نتيجه نهايي اين است که اگر از فايل هاي ثبت وقايع خود به صورت روزانه پشتيبان مي گيرد، مي توانيد از هدر رفتن مقدار زيادي ديسک برتر جلوگيري کنيد (به هر حال از ديدگاه قابليت بازيابي، پشتيبان گيري روزانه، کار نادرستي محسوب مي شود). از آن جائيکه پشتيبان گيري هاي فايل ثبت وقايع و عمل کوتاه سازي مربوطه بسيار اجرايي است، استفاده از پشتيبان گيري هاي مرتب و مکرر فايل ثبت وقايع، مي تواند مقدار ظرفيت موجود ديسک برتر را به حداکثر برساند. مثلاً زمان بندي ساعات اداري را در تصوير2 در نظر بگيريد، که در آن اکثر به روزرساني ها و اصلاحات در ساعت پيک صورت مي گيرند. در مورد بانک اطلاعاتي 100GB که قبلاً عنوان کرديم، پشتيبان گيرهاي ساعتي از ثبت ها، موجب مي شود که فايل ثبت وقايع فقط 4GB باشد، يعني تقريباً در هر ساعت در ساعات پيک، 1 تا 2GB اصلاحات و همچنين padding فراوان را متقبل مي شود. پشتيبان گيري ساعتي موجب مي شود تا تراکنش هاي کامل شده و به شکلي مطمئن و امن ثبت ودر ديسک غير برتر پشتيبان گيري شوند، و به اين ترتيب بيش از 20GB از ديسک برتر را خالي مي کند، بدون آنکه عملکرد يا اطمينان پذيري را قرباني نمايد. در سيستم هاي بزرگتر که آرام آرام با گذشت زمان رشد کرده و بزرگ مي شوند، اين روش، اگر به درستي استفاده شود، مي تواند نياز به خريدن حافظه برتر اضافي را کاهش دهد.

عملکرد بالاتر، پول کمتر:
 

مديريت عملکرد ديسک، مستلزم تلاش، تنظيم و تي و يک کردن و حتي فرضيات هوشمندانه است. به هر حال، به تلاشش مي ارزد. با استفاده ي خلاقانه از منابع موجود، مي توانيد کارآيي زير سيستم هاي گران قيمت I/O خود را به حداکثر برسانيد، به اين ترتيب عمل کرد کل SQL Server تقويت مي شود و در هزينه هم صرفه جويي مي گردد. در غير اين صورت مي بايد هزينه اي را صرف ارتقاء راهکارهاي ذخيره سازي يا خريداري حافظه جديد نمائيد.
منبع:ماهنامه ي رايانه شماره 188