بایگانی‌ها مقالات تخصصی

Veeam Scale-Out Backup Repository

۱۳۹۷-۰۸-۰۹/۰ دیدگاه /در Virtualization, مقالات تخصصی /توسط فاطمه بیگلو

Veeam Scale-Out Backup Repository

شما می توانید Scale-Out Repository را به عنوان یکی از کابردی ترین خصوصیات نرم افزار Veeam در زیرساخت پشتیبان گیری پیکربندی کنید. Scale-Out Repository به صورت Logical تنظیم و راه اندازی می شود. با همبندی چند Repository در کنار هم فضای قابل استفاده را افزایش می دهد و شما در هر زمانی می توانید فضای در اختیار را بزرگ نمایید. هنگامی که شما Scale-Out Repository را پیکربندی می کنید، شما در واقع یک مجموعه ای از دستگاه های ذخیره سازی و سیستم ها را ایجاد می کنیدکه ظرفیتی معادل مجموع Repository ها برای شما در قالب یک Volume فراهم می نماید.

با استفاده از این قابلیت شما می توانید در هر زمانی فضای در حال استفاده را افزایش دهید به عنوان مثال اگر فضای شما در حال پر شدن باشد ، می توانید با ایجاد یک فضای جدید و اضافه کردن آن به گروه Scale-Out Repository ،بدون کوچکترین مشکلی فضا را افزایش می دهید و دیگر لازم نیست دیتاهای قبلی را جا به جا نمود.

برای ایجاد Scale-Out Repository می توان چندین Repository از جنس های متفاوت را با هم تجمیع و در یک Scale-Out Repository ارائه کرد که این خصوصیت Veeam با Repository های زیر سازگار می باشد:

Microsoft Windows backup repositories
Linux backup repositories
Shared folders
Deduplicating storage appliances

این امکان وجود دارد که به عنوان مثال یک Microsoft Windows backup repositories و یک Deduplicating storage appliances را در یک فضا تجمیع و استفاده نمود.

در این نوع Repository انواع راهکارهای پشتیبان گیری و بازیابی اطلاعات قابل استفاده می باشد.

توصیه های ESXI در خصوص SAN Multipathing برای دستیابی به بالاترین میزان عملکرد

۱۳۹۷-۰۶-۰۵/۰ دیدگاه /در Virtualization, مقالات تخصصی /توسط فاطمه بیگلو

توصیه های ESXI در خصوص SAN Multipathing برای دستیابی به بالاترین میزان عملکرد

سیاست های SAN Path، می تواند تاثیر قابل توجهی بر روی عملکرد ذخیره سازی داشته باشد. به طور کلی سیاستی که ESXI به طور پیش فرض برای یک آرایه خاص استفاده می کند، بهترین انتخاب خواهد بود. اگر سیاست های غیر پیش فرض را انتخاب می کنید، توصیه می کنیم از میان پالیسی های تست شده و پشتیبانی شده توسط فروشنده ی ذخیره ساز خود انتخاب کنید. در این بخش خلاصه ای از پالیسی های SAN Path را مطرح می کنیم.

توصیه های ESXI

برای اکثر آرایه های ذخیره سازی فعال / غیرفعال، ESXi به طور پیش فرض از پالیسی بیشترین مسیر اخیرا به کار رفته (MRU) استفاده می کند. ما توصیه نمی کنیم که از سیاست مسیر ثابت برای آرایه های ذخیره سازی فعال / غیرفعال استفاده کنید، به این دلیل که این می تواند موجب تعویض مسیر مکرر و سریع شود و می تواند در دسترسی به LUN کندی ایجاد کند. برای عملکرد مطلوب با آرایه هایی که ESXi به طور پیش فرض به MRU می پردازد، شما ممکن است پالیسی Round Robin را در نظر بگیرید. برای برخی از آرایه های active/passive که ALUA را پشتیبانی می کند، ESXI می تواند از پالیسی مسیر ثابت استفاده کند. اما توصیه می شود از آن زمانی استفاده کنید که توسط vendor شما پشتیبانی شود. در اکثر موارد پالیسی Round Robin برای آرایه های active/passive انتخاب بهتر و امن تری است.
برای اکثر آرایه های ذخیره سازی فعال/فعال، ESXI به طور پیش فرض از پالیسی مسیر ثابت استفاده می کند. زمانی که از این پالیسی استفاده می شود شما می توانید استفاده از پهنای باند خود را با تعیین مسیر های مورد نظر به هر LUN از میان کنترلرهای مختلف ذخیره ساز به حداکثر برسانید. برای دستیابی به عملکرد مطلوب با این آرایه ها شما ممکن است از پالیسی Round Robin استفاده کنید.
ESXI می تواند از پالیسی Round Robin که می تواند performance ذخیره سازی را در برخی محیط ها بهبود دهد، استفاده کند. پالیسی Round Robin، Load Balancing را میان تمامی مسیر های فعال فراهم می کند و تعداد درخواست های I/O ثابت یا قابل تنظیمی را به هر مسیر active می فرستد. همه ی آرایه های ذخیره سازی Round Robin را پشتیبانی تمی کنند، استفاده از پالیسی هایی که توسط vendor ذخیره ساز پشتیبانی نمی شود می تواند مشکلاتی را در ارتباط با دسترسی به LUN به وجود آورد. توصیه می شود داکیومنت های مربوط به vendor حتما بررسی شود و در صورت پشتیبانی از Round Robin و توصیه به استفاده از آن توسط Vendor، از آن بهره ببرید.
ESXI همچنین از third-party path selection plugins(PSPs) نیز پشتیبانی می کند. این ممکن است بهترین Performance را برای یک آرایه ی خاص با بهره برداری از یک ویژگی خاص و دانش طراحی آن فراهم کند.
اگر ذخیره ساز شما قابلیت ALUA را پشتیبانی می کند، فعال کردن این ویژگی در برخی از محیط ها می تواند موجب بهبود performance گردد. ALUA که به طور خودکار توسط ESXI شناسایی می شود، اجازه می دهد که خود آرایه ی ذخیره سازی مسیری را به عنوان مسیر فعال بهینه تعیین کند. زمانی که ALUA با پالیسی Round Robin ترکیب می شود، ESXI به طور پیش فرض درخواست های I/O را از میان این مسیرهای active بهینه عبور می دهد.

(Veeam (Backup Job Encryption

۱۳۹۷-۰۶-۰۳/۰ دیدگاه /در Virtualization, مقالات تخصصی /توسط فاطمه بیگلو

(Veeam (Backup Job Encryption

رمزنگاری برای Backup Job در نرم افزار Veeam از قسمت تنظیمات پیشرفته مربوط به Job ها مطابق شکل زیر صورت می پذیرد.

در هنگام ایجاد و تعریف یک Job از Wizard مربوطه از قسمت Storage بر روی گزینه تنظیمات پیشرفته Advanced کلیک می نماییم و پس از باز شدن صفحه جدید از زبانه Storage در قسمت Encryption گزینه مربوط به رمزنگاری بکاپ ها را فعال می نماییم سپس بر روی گزینه Add کلیک کرده و رمز دلخواه خود را انتخاب می نماییم.

توجه داشته باشید که می بایستی از رمز مورد نظر محافظت نموده و هرگز آن را فراموش ننمایید در غیر اینصورت بکاپ مورد نظر بلااستفاده بوده و قابلیت بازگردانی را ندارد.

مراحل فعال کردن رمزنگاری بر روی بکاپ ها بصورت زیر می باشد :

فعال کردن رمزنگاری برای بکاپ ها و مشخص کردن پسورد
نرم افزار Veeam Backup & Replication کلید لازم برای محافظت از بکاپ ها را تولید می کند.
نرم افزار Veeam Backup بلاکهای داده را درBackup Proxy رمزنگاری می کند و آنها را به backup repository انتقال می دهد.
در backup repository بلوک داده رمزگذاری شده به یک فایل پشتیبان تهیه شده ذخیره می شود.

Source : https://helpcenter.veeam.com/docs/backup/vsphere/encryption_backup_job.html?ver=95

فعال کردن QuickConnect در سینولوژی

۱۳۹۷-۰۵-۱۶/۰ دیدگاه /در Storage /توسط فاطمه بیگلو

فعال کردن QuickConnect در Synology

QuickConnect اجازه اتصال کاربران به دستگاه سینولوژی را از طریق اینترنت بدون هیچ زحمتی در تنظمیات مربوط به Port Forwarding را می دهد. با استفاده از QuickConnect می توان به بسته های توسعه داده شده سینولوژی مانند ایستگاه صدا – تصویر – دانلودها – عکس ها – فایل ها – CMS و برنامه های موبایل دسترسی داشت

نحوه فعال کردن QuickConnect :

۱- به مسیر مشخص شده زیر می رویم

Control Panel > QuickConnect > General

چک مربوط به QuickConnect را فعال می نماییم
در این قسمت می بایستی اطلاعات مربوط به کاربر سینولوژی که از قبل ایجاد نموده ایم را وارد کنیم در غیر اینصورت می بایستی یک کاربر جدید را در سایت سینولوژی ایجاد نماییم.
مشخص کردن یک شناسه جدید QuickConnect و اطمینان از اینکه آن را به یاد داشته باشید.

بنابراین شما توانایی اتصال و دسترسی در هر زمانی را دارید.

بر روی Apply کلیک می نماییم.

تذکر :

شناسه مربوط به QuickConnect می تواند شامل حروف ، اعداد و خطوط – باشد و می بایستی با یک حرف آغاز شود.

ارتباط پیشرفته QuickConnect

سینولوژی گزینه های پیشرفته برای ایجاد دسترسی QuickConnect با محیط های شبکه مختلف و سازگاری با آنها را پیشنهاد می دهد.

برای فعال کردن این گزینه بصورت زیر عمل می نماییم :

۱- به مسیر زیر می رویم

Control Panel > QuickConnect > Advanced

۲- یکی از موارد زیر را که مناسب احتیاج شماست انتخاب می نماییم :

– فعال کردن QuickConnect توسط سرویس Relay (واسط) : اتصال سریع شما بوسیله سینولوژی سرور Relay (واسط) برقرار خواهد شد موقعی که دسترسی بطور مستقیم به سینولوژی توسط QuickConnect در محیط شبکه فعلی امکان پذیر نباشد.

– قوانین ایجاد اتوماتیکی Port Forwarding : اگر روتر شما تست های مربوط به سازگاری را پاس نماید قوانین مربوط به Port Forwarding بصورت اتوماتیکی برای QuickConnect ایجاد می گردد.

– در انتها گزینه مربوط به Apply را برای تایید کلیک می نماییم.

فعال و غیرفعال کردن QuickConnect برای برنامه ها و سرویس های مشخص :

۱- به مسیر مشخص شده در زیر می رویم

Control Panel > QuickConnect > Advanced

۲- برنامه ها و سرویس هایی که برای QuickConnect می خواهیم فعال نماییم را مشخص می کنیم

۳- گزینه Apply را به نشانه تایید کلیک می نماییم

برای بهتر شدن راندمان و کارایی QuickConnect پیشنهاد می شود از طریق مسیر زیر Port Forwarding را به ازای هریک از سرویس ها پیکربندی نمایید : Control Panel > External Access > Router Configuration

DSM: 5000 (HTTP); 5001 (HTTPS)

Photo Station: 80 (HTTP); 443 (HTTPS)
Cloud Station：۶۶۹۰

Resource:https://www.synology.com/englobal/knowledgebase/DSM/help/DSM/AdminCenter/connection_quickconnect

قابلیت موجود در VMware به نام EVC

۱۳۹۷-۰۴-۳۱/۰ دیدگاه /در Virtualization, مقالات تخصصی /توسط فاطمه بیگلو

قابلیت موجود در VMware به نام EVC

بحث این مقاله در مورد قابلیت موجود در VMware به نام EVC می باشد که با بحث VMotion مرتبط است. زمانیکه شما می خواهید در یک Cluster در VMware ماشین های مجازی خودتان را از Host ای به Host دیگر منتقل کنید حتما باید نوع CPU سرور اول با نوع CPU سرور دوم مشابه باشد تا بتوانید به درستی VMotion را انجام دهید. این یک مشکل حاد در VMotion محسوب می شود چراکه همیشه Host های شما از یک نوع سخت افزار نیستند و بعضا ممکن است در یک Cluster چندین Host مختلف با انواع CPU های مختلف داشته باشید که با این شرایط شما نمی توانید عملیات VMotion را انجام دهید. برای حل کردن این مشکل شرکت VMware بعد از معرفی محصول VMware ESX 3.5 Update 2 قابلیتی به نام EVC یا Enhanced VMotion Compatibility را معرفی نمود که برای برطرف کردن همین مشکل ارائه شده بود.

EVC این قابلیت را به محیط مجازی سازی VMware می دهد که بتوانید VM های خودتان را بین Host های مختلف ESXi که دارای CPU های مختلف می باشندVMotion کنید. روش کاری EVC به این شکل است که در هنگام انتقال یا VMotion کردن VM ها قابلیت های CPU ای که بین سیستم مبدا و سیستم مقصد یکسان نیستند و یا سیستم مقصد از آنها پشتیبانی نمی کند را از داخل VM ها حذف می کند تا به یک درجه مساوی از قابلیت ها برسد ، برای مثال مواردی از قبیل Clock Speed و یا تعداد Core های CPU را در بین Host ها تغییر می دهد تا با همدیگر تناسب پیدا کنند. این قابلیت با انواع نسخه های مختلف CPU که از یک سازنده و برند باشند کار می کند. به این مورد کاملا دقت کنید که VMware EVC نمی تواند بین پردازنده های AMD و Intel فرآیند VMotion را انجام دهد اما قبل از اینکه بخواهد فرآیند VMotion را انجام دهد سیستم Host اول و Host دوم را از نظر هماهنگ بودن نوع CPU ها با همدیگر بررسی می کند و اگر عدم هماهنگی وجود داشته باشد به شما گزارش می دهد. البته به غیر از قابلیت EVC شرکت VMware یک قابلیت ساده تر به نامCompatibility Mask CPU وجود دارد که با استفاده از آن می تواند برخی از قابلیت های CPU را از VM ها پنهان کند اما این قابلیت پیشنهاد نمی شود. درست است که EVC هم تقریبا چنین کاری انجام می دهد اما EVC همیشه هم نمی تواند باعث شود که VM نتواند به قابلیت های CPU دسترسی داشته باشد و این بستگی به نرم افزارها و Application هایی دارد که بر روی ماشین مجازی نصب شده اند.

شما می توانید بصورت پیشفرض فقط VMotion را بر روی Host هایی انجام دهید که ساختار CPU های آنها یا کاملا مثل هم هستند و یا بسیار شبیه به هم هستند. این موضوع باعث می شود که سازمان در خرید کردن سرورهای جدید و اضافه کردن آنها در Cluster مجازی سازی خود کمی دچار مشکل شود. تصور کنید که شما در حال حاضر در سازمان خود یک سری سرور Host با برند HP مدل G6 دارید که بر روی آنها از قبل ESX نصب شده است و دارای سری خاصی از CPU های شرکت Intel هستند و در نهایت درون Cluster قرار گرفته اند. حال سازمان شما تصمیم می گیرد که برای رشدی که در آینده خواهد داشت ، یک سری سرور جدید برند HP مدل G9 را به مجموعه Cluster اضافه کندکه آنها هم برای خودشان دارای یک سری خاص CPU هستند.

زمانیکه شما می خواهید عملیات VMotion را برای VM های این Host ها که دارای CPU های متفاوتی هستند انجام دهید اتفاقی که می افتد این است که در لایه سیستم عاملی که در VM نصب شده است ، VM دارای یک سری دستورالعمل ها و اطلاعات درون CPU است زمانیکه VMotion می شوند و در Host جدید قرار می گیرند به دلیل مشابه نبودن ساختار CPU قادر به اجرا و ادامه کار نخواهند داشت ، این موضوع باعث می شود که در سیستم عامل های ویندوز مجازی شما با صفحات Blue Screen و در سیستم عامل های لینوکس مجازی با مشکل Kernel Crash مواجه شوید ، دلیل بروز مشکل کاملا مشخص است ، دستورات و داده هایی که در CPU وجود داشتند به دلیل عدم هماهنگی بین CPU ها به یکباره دیگر در دسترس نخواهند بود.

برای جلوگیری از به وجود آمدن اینگونه Crash های سیستم عامل مجازی دو تکنیک مختلف استفاده می کند. اولین تکنیک زمانیکه مدیر شبکه درخواست انجام فرآیند VMotion را صادر می کند vCenter Server هم CPU مبدا و هم CPU مقصد را ارزیابی می کند و بررسی می کند که آیا هر دوی این CPU ها توانایی انجام شدن VMotion را دارند یا خیر ، اگر امکان انجام VMotion وجود نداشته باشد در همان لحظه به مدیر شبکه اطلاع رسانی خواهد شد. اما روش دوم که تا حدودی هم به آن اشاره کردیم به نام CPU Masking معروف است. CPU Masking کاری می کند که قابلیت هایی که بر روی CPU وجود دارند بر روی VM قابل مشاهده نباشند و در واقع به VM گفته نمی شود که CPU ای که از آن استفاده می کند چه قابلیت هایی دارد ، بنابراین سیستم عامل موجود در VM هم هیچ دیدی از نوع CPU ای که استفاده می کند نخواهد داشت این تکنیک باعث می شود که قابلیت های اضافه تری که معمولا باعث ایجاد شدن Crash در VM ها در زمان VMotion می شوند عملا از نظر سیستم عامل مجازی وجود نداشته باشد که باعث به وجود آمدن Crash بشود. اما تکنیک VMware Enhanced VMotion Compatibility یا EVC یک لایه از CPU Masking معمولی بالاتر است ، در CPU Masking قابلیت های CPU در لایه سیستم عامل مجازی مخفی می شود اما در EVC مخفی کردن یا CPU Masking در لایه Host انجام می شود و طبیعتا در درجه بالاتری انجام می شود. دقت کنید که EVC هم بستگی به نرم افزارهایی دارد که از امکانات خاص CPU مثل CPUID استفاده می کنند ممکن است به درستی کار نکند و دچار مشکل شود اما تعداد نرم افزارهایی که به گونه ی برنامه نویسی می شوند که مثلا با قابلیت خاص CPU کار کنند بسیار معدود است و همین باعث می شود که EVC تقریبا بتواند در بیشتر موارد کار را به درستی انجام دهد.

Synology high availability

۱۳۹۷-۰۴-۱۹/۰ دیدگاه /در SYNOLOGY, مقالات تخصصی /توسط فاطمه بیگلو

Synology high availability

سینولوژی جهت جلوگیری از مشکلات سخت افزاری احتمالی برای تجهیز، راهکاری در قالب کلاستر ارائه کرده است. در این راهکار امکان ساختن یک کلاستر با دو تجهیز سازگار سینولوژی وجود دارد و یک تجهیز به صورت Active و تجهیز دیگر به صورت Passive می باشد. مفهوم کلاستر در واقع ایجاد یک فضای ذخیره سازی برای هر دو تجهیز می باشد که این فضا در ابتدا در اختیار سرور Active می باشد و در هنگام رخ دادن خطا ، توسط Cluster Management به سرور Passive منتقل می گردد.کلیه سرویس ها بر روی سرور Active می باشد و سرور Passive در حال Standby می باشد و در موقع رخداد خطا بلافاصله وارد مدار می شود.

Heartbeat connection

دو سرور Active و Passive توسط یک لینک شبکه اختصاصی و ایزوله به یکدیگر متصل می گردند که توسط این لینک بسته های HeartBeat به یکدیگر ارسال می کنند و از وضعیت تجهیز مقابل خود آگاه می شود و هنگامی که به هر دلیلی این بسته ها دریافت نشود، خطا تشخیص می دهد و عملیات سوییچینگ را جهت Active نمودن سرور Passive انجام می دهد.

نکته : این لینک بسیار حساس می باشد لذا گاهی لازم است تنظیماتی از قبیل Jumbo Frame و با PortFast بر روی سوییچ صورت پذیرد.

Network

برای برقراری ارتباطی مطمئن و استفاده بهتر از پورت های شبکهی تجهیز ، در لایه شبکه HighAvailability به صورت Link Aggregation و یا Active/Standby پیاده سازی شود

Disk Station Manager چیست

۱۳۹۷-۰۴-۱۱/۰ دیدگاه /در Storage, SYNOLOGY /توسط فاطمه بیگلو

(DSM(Disk Station Manager چیست؟

Disk Station Manager ( DSM ) یک Operation Environment بر مبنای سیستم عامل Linux می باشد که دسترسی به آن از طریق وب است که مخصوص محصولات سینولوژی طراحی شده است با DSM به سرعت و آسانی می توانید موارد زیر را انجام دهید :

اصلاح و شخصی سازی تنظیمات سیستم
نصب و باز کردن برنامه های کاربردی و بسته های مربوطه
ایجاد Raid و مدیریت انواع دیگر فضای ذخیره سازی

ورود به DSM

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

مراحل ورود به سیستم :

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

synology.com ( تنها در حالتی که کامپیوتر و سینولوژی به اینترنت متصل هستند )
وارد کردن نام سینولوژی به همراه پورت ۵۰۰۰ بطور مثال diskstation:5000 ( شناسه نام سرور به تنظیمات اولیه در حین نصب سینولوژی وابسته است )
وارد کردن آدرس IP دستگاه سینولوژی به همراه پورت ۵۰۰۰ بطور مثال ۱۶۸.۴۸.۱۴:۵۰۰۰

( تعیین آدرس IP به تنظیمات اولیه در حین نصب سینولوژی وابسته است )

وارد کردن نام کاربری به همراه گذرواژه برای ورود به دیتگاه سینولوژی

تذکر :

نام و آدرس IP و همچنین گذرواژه در هنگام نصب سینولوژی می بایستی تنظیم گردد. اگر با پیدا کردن این اطلاعات مشکلی دارید از نرم افزار معاون سینولوژی استفاده نموده یا از find.synology.com استفاده نمایید

DSM Desktop

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

نوار وظیفه

نوار وظیفه در بالای صفحه واقع شده است و شامل موارد زیر می باشد :

نمایش صفحه( Show Desktop ) : کوچک کردن تمام برنامه های باز و صفحات بسته ها
منو اصلی ( Main Menu ) : از این قسمت میتوان برنامه های باز و بسته های نصب شده بر روی دستگاه سینولوژی را مشاهده نمود. شما همچنین می توانید با کلیک کردن و کشیدن میانبر بر روی صفحه نمایش ایجاد نمایید.
برنامه های باز ( Open applications ) : نمایش بسته های باز و همچنین برنامه های باز جاری از این قسمت میسر می باشد

شما می توانید راست کلیک کرده و آن را به نوار وظیفه برای دسترسی سریعتر در آینده سنجاق نمایید

صف بارگذاری ( Upload Queue ) : زمانی که شروع به بارگذاری فایل ها بر روی سینولوژی می کنید ظاهر می شود که با کلیک کردن بر روی این قسمت می توانید جزییات بیشتری مانند در حال انجام بودن و یا سرعت بارگذاری را مشاهده نمایید.
دستگاه های بیرونی ( External Devices ) : زمانی که دستگاه های بیرونی به سینولوژی متصل می شود از این قسمت نمایش داده می شود
اطلاع رسانی ( Notifications ) : نمایش اطلاع رسانی از این قسمت می باشد بطور مثال خطاها ، وضعیت بروز رسانی و بسته های نصب شده
گزینه ها Options ) ( : خاموش کردن و راه اندازی مجدد ، خروج از سیستم و یا تغییر گزینه های حساب شخصی از این قسمت می باشد
جستجو ) Search (: پیدا کردن سریع برنامه های کاربردی خاص و بسته های نرم افزاری یا عنوان های کمک DSM
ابزارک ها Widgets ) ( : نمایش یا مخفی کردن ابزارک ها
نمایش آزمایشی ( Pilot View ) : نمایش تمامی برنامه های باز و بسته ها

ایجاد میانبر صفحه نمایش :

باز کردن منو اصلی
کلیک کردن و کشیدن برنامه ها یا بسته ها به اطراف

Resource :

https://www.synology.com/en-us/knowledgebase/DSM/help

توصیه های عمومی ذخیره سازی ESXI

۱۳۹۷-۰۴-۰۱/۰ دیدگاه /در Virtualization, مقالات تخصصی /توسط فاطمه بیگلو

توصیه های عمومی ذخیره سازی ESXI

تعداد LUN ها در یک آرایه ی ذخیره سازی و راهی که ماشین های مجازی در سراسر این LUN ها توزیع شده اند می تواند بر روی performance تاثیر گذارد. فراهم کردن LUN های بیشتر، با ماشین های مجازی کمتر بر روی هر یک، می تواند سرورهای ESXi را قادر سازد تا به طور همزمان درخواست های ورودی / خروجی بیشتری را به آرایه ذخیره سازی ارائه دهند. این قابلیت بالقوه ای برای بهبود عملکرد، با اطمینان استفاده کامل از تمام منابع آرایه و ارائه فرصت های بیشتری برای بهینه سازی I/O به آرایه ذخیره سازی است. از سوی دیگر ایجاد کردن LUN های خیلی زیاد، مخصوصا زمانی که سرورهای ESXI زیادی به یک ذخیره ساز تنها متصل شده اند، می تواند موجب شود هاست های ESXI به طور همزمان درخواست های I/O بسیار زیادی را که منجر به پر شدن صف آرایه ذخیره ساز و ارسال خطاهای QFULL/BUSY از سوی آرایه ذخیره سازی می شود. این مسئله می تواند موجب کاهش performance و نیاز به تلاش مجدد برای درخواست های reject شده شود.

آمار تاخیر در I/O را می توان با استفاده از esxtop و یا resxtor که گزارش زمان تاخیر دستگاه، زمان صرف شده در kernel و تاخیر دیده شده توسط سیستم عامل guest را می دهد، مانیتور کرد.

اطمینان حاصل کنید که تأخیر میانگین برای دستگاه های ذخیره سازی بسیار زیاد نیست. این تأخیر را می توان با مشاهده در esxtop و با جستجوی متریک GAVG / cmd. دید. مقدار معقول مناسب برای این معیار به زیر سیستم ذخیره سازی شما بستگی دارد. به طور پیش فرض storsge I/O control setting ، ۳۰ میلی ثانیه است اما اگر شما storage سریع تری دارید مثلا SSD، می توانید این مقدار را کاهش دهید.

شما می توانید حداکثر تعداد درخواست های دیسک را در هر VMFS Volume تنظیم کنید، که می تواند کمک کند پهنای باند ماشین های مجازی که از آن Volume استفاده می کنند را برابر کنید.

اگر شما اغلب خطاهای QFULL / BUSY را مشاهده می کنید، ممکن است enable و تنظیم کردن عمق صف موجب بهبود عملکرد ذخیره سازی شود. این ویژگی می تواند به طور قابل توجهی تعداد دستورات برگشت داده شده از آرایه با خطای QFULL / BUSY را کاهش دهد. اگر هر سیستم دسترسی به یک LUN خاص یا پورت آرایه ذخیره سازی با queue depth throttling فعال شده دارند، تمام سیستم ها دسترسی به این LUN یا پورت آرایه ذخیره سازی باید از الگوریتم عمق صف استفاده کنند.

امکانات Veeam SureBackup

۱۳۹۷-۰۳-۲۶/۰ دیدگاه /در Virtualization, مقالات تخصصی /توسط فاطمه بیگلو

قابلیت Veeam SureBackup

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

نرم افزار Veeam با درک اهمیت این موضوع قابلیتی با نام SureBackup راه اندازی نموده است. این قابلیت صحت عملکرد نسخه های پشتیبان را در محیطی ایزوله آزمایش می نماید و گزارشی از صحت عملکرد آن ارائه می نماید.

جهت استفاده از این قابلیت به موارد زیر نیاز می باشد:

Application Group : در زمان ریکاوری ماشین ها ، گاهی برخی از ماشین ها لازم است تا با هم شروع به کار نمایند تا بتوان عملکرد صحیح آنها را سنجید.در واقع گروهی از ماشین های وابسته به هم از لحاظ عملکرد می باشد.
Virtual Lab: محیطی ایزوله جهت اجرای ماشین های داخل Application Group می باشد که تست و عملکرد آنها بررسی می گردد.
SureBackup Job: در واقع یک Task که جهت اجرای صحت عملکرد عملیات ریکاوری ایجاد می گردد که هم به صورت Manual و هم به صورت Automatically Schedule قابل اجرا می باشد.

مراحل اجرا :

Veeam ابتدا ماشین ها را از قسمت Application Group با همان شکل فشرده شده که ذخیره شده است در محیطی ایزوله که معروف به Virual Lab می باشد به صورت Instant vm recovery فرا می خواند.
تست ها در سه مرحله برای VM Backup Files اجرا می شود که شامل Heartbeat Test ، Ping Test و Application Test می باشد.
در صورتی که Job مربوطه دارای صحت عملکرد باشد نرم افزار Veeam یک CRC Check ایجاد می کند شامل اینکه کدام ماشین استارت و تایید شده است و کدام VM Backup Files از کدام Application Group اجرا شده است و پس از اتمام مراحل ، تاییدیه مربوط به فایل پشتیبان صادر می گردد.
پس از اینکه عملیات بررسی صحت ریکاوری به اتمام رسید ، Veeam ماشین ها را اصطلاحا Unpublished می نماید و گزارشی تهیه و در صورت لزوم ایمیل می نماید.

لازم به ذکر است خصوصیت SureBackup در لایسنس های Enterprise Plus و Enterprise در دسترس می باشد.