QUICK BOOT در VSPHERE 6.7

/۰ دیدگاه /در , , , /توسط

QUICK BOOT  در VSPHERE 6.7

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

متاسفانه ریبوت کردن سرور فیزیکی باید در زمان های خاصی انجام شود مثلا :

  • آپدیت ESXi
  • نصب VIB جدید و ….

قابلیت فوق العاده ای که در ورژن vSphere 6.7 داریم قابلیت Quick Boot هست. این قابلیت Hypervisor رو ریبوت می کند ولی سرور فیزیکی رو ریبوت نمی کند.

اگر تا به حال با استفاده از VUM سرور ESXi رو آپدیت کرده باشید می دانید که برای آپدیت دو بار ESXi راریبوت می کند با استفاده از این قابلیت این تعداد به یک عدد کاهش پیدا می کند برای همین باعث می شود زمان Downtime  خیلی کاهش پیدا کند.

چگونگی فعال سازی قابلیت Quick BOOT

پس از login به vCenter مسیر Home -> Update Manager -> Manage- > Settings -> Host/Cluster Settings -> Edit را طی کنید.

سپس چک باکس Enable Quick Boot را انتخاب کنید.

اگر سخت افزار سرور شما با این قابلیت compatible نباشد، به صورت نرمال بوت خواهد شد. در پنجره ی Select target objects به شما اطلاع داده می شود که کدام سرورها از این قابلیت پشتیبانی می کنند.

Veeam Scale-Out Backup Repository

/۰ دیدگاه /در , /توسط

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 های زیر سازگار می باشد: apoteketgenerisk.com

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

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

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

معرفی VMware vSAN

/۰ دیدگاه /در , /توسط

معرفی VMware vSAN

 VMware vSAN از یک رویکرد تعریف شده توسط نرم افزار که ذخیره ساز مشترک را برای ماشین های مجازی ایجاد می کند استفاده می کند. این مجازی سازی، منابع ذخیره سازی فیزیکی محلی میزبان های ESXi را به مخازن ذخیره سازی تبدیل می کند که می تواند به صورت share به ماشین های مجازی و برنامه های کاربردی اختصاص داده شود. vSAN به طور مستقیم در hypervisor ESXi  اجرا می شود.

پیکربندی

شما می توانید vSAN را به گونه ای پیکربندی کنید تا به عنوان یک کلاستر ترکیبی و یا تمام فلش کار کند. در کلاستر های ترکیبی، درایوهای فلش برای لایه کش استفاده می شوند و دیسک های مغناطیسی برای لایه ظرفیت ذخیره سازی استفاده می شوند. در کلاستر های تمام فلش، درایوهای فلش برای هر دو حافظه پنهان و ظرفیت استفاده می شوند.

شما می توانید vSAN را بر روی کلاسترهای هاست موجود و یا هنگامی که کلاستر های جدید ایجاد می کنید فعال کنید.    vSAN  تمام دیسک درایوهای محلی را به یک datastore مجزا که توسط تمام هاست ها در کلاستر vSAN به اشتراک گذاشته شده است، جمع آوری می کند. شما می توانید datastore را با اضافه کردن دیسک درایو و یا اضافه کردن هاست هایی با درایوهای ظرفیت به کلاستر گسترش دهید. vSAN زمانی در بهترین حالت کار می کند که همه ی هاست های ESXi موجود درکلاستر، پیکربندی مشابه ای از جمله پیکربندی ذخیره سازی مشابه داشته باشند. این پیکربندی سازگار، اجزای ذخیره سازی ماشین های مجازی را در تمام درایوها و هاست ها درکلاستر متعادل می کند. همچنین میزبان های بدون دیسک درایوهای محلی نیز می توانند ماشین های مجازی خود را در datastore مربوط به vSAN  شرکت دهند و اجرا کنند.

اگر یک میزبان دیسک درایوهای محلی خود را به datastore vSAN اضافه کند، باید حداقل یک درایو برای حافظه فلش و حداقل یک درایو برای ظرفیت ارائه دهد. درایو های ظرفیت دیسک های داده نیز نامیده می شوند.

دیسک درایو های هاست های شرکت کننده در کلاستر یک یا چند گروه دیسک را تشکیل می دهند. هر گروه دیسک حاوی یک درایو ذخیره سازی فلش و یک یا چند درایو ظرفیت برای ذخیره سازی دائمی است. هر میزبان می تواند برای استفاده از چندین گروه دیسک پیکربندی شود.

vSAN و ذخیره سازی سنتی در موارد زیر با یکدیگر تفاوت هایی دارند.

  • vSAN برای ذخیره سازی فایل های ماشین های مجازی از راه دور، به شبکه ی ذخیره سازی خارجی مانند کانال فیبر (FC) یا شبکه ذخیره سازی (SAN) نیاز ندارد.
  • با استفاده از ذخیره سازی سنتی، مدیر ذخیره سازی فضای ذخیره سازی را بر روی سیستم های مختلف ذخیره سازی به طور پیش فرض قرار می دهد. vSAN به طور خودکار منابع ذخیره سازی فیزیکی محلی میزبان های ESXi را به یک واحد ذخیره سازی تبدیل می کند. این Pool ها را می توان تقسیم کرد و به ماشین های مجازی و برنامه های کاربردی بر اساس الزامات کیفیت خدمات شان اختصاص داد.
  • vSAN مانند Volume های ذخیره سازی سنتی بر اساس LUN ها یا NFS رفتار نمی کند. سرویس Target iSCSI  از LUN ها برای راه اندازی یک initiator در یک میزبان از راه دور برای انتقال داده ها در سطح بلاک به یک دستگاه ذخیره سازی در کلاستر vSAN استفاده می کند.
  • برخی از پروتکل های ذخیره سازی استاندارد، مانند FCP، به vSAN اعمال نمی شود.
  • vSAN بسیار با vSphere یکپارچه شده است. در مقایسه با ذخیره سازی سنتی، شما نیاز به پلاگین اختصاصی یا یک کنسول ذخیره سازی برای vSAN ندارید .  شما می توانید vSAN را با استفاده از vSphere Client یا vSphere Web Client نصب، مدیریت و نظارت کنید.
  • یک مدیر ذخیره سازی اختصاصی برای مدیریت vSAN نیاز نیست. در عوض یک مدیر vSphere میتواند محیط vSAN را مدیریت کند.
  • با vSAN، سیاست های ذخیره سازی VM به طور خودکار زمانی که شما VM جدید را راه اندازی می کنید، اختصاص داده می شود. سیاست های ذخیره سازی را می توان به صورت پویا در صورت نیاز تغییر داد.

نصب و راه اندازی Vmware Tools در لینوکس

/۰ دیدگاه /در , /توسط

نصب و راه اندازی Vmware Tools در لینوکس

برای نصب و راه اندازی Vmware Tools  بر روی سیستم عامل لینوکس که توزیع RPM  را ساپورت نمی کند و یا کرنل مربوطه ان تغییر یافته است ( سیستم عامل هایی غیر از Redhat Linux )  در محیط Vmware  مراحل زیر را به ترتیب دنبال می نماییم :

  • از روشن بودن ماشین مجازی اطمینان پیدا می کنیم
  • در صورت استفاده از محیط گرافیکی Command Shell ( محیط متنی ) لینوکس را باز می نماییم

لازم بذکر است می بایست با کاربر Root  به سیستم Login  نمایید یا می بایست با دستور Sudo  هریک از مراحل زیر را  کامل نمایید

  • در محیط مجازی ESXI بر روی ماشین مورد نظر راست کلیک کرده و از قسمت Guest گزینه Install / Upgrade Vmware Tools  را انتخاب می نماییم و گزینه OK  را انتخاب می نماییم
  • دستور زیر را در محیط لینوکس اجرا می نماییم با استفاده از دستور زیر دایریکتوری به نام Cdrom در قسمت  mnt  ایجاد می نماییم

mkdir /mnt/cdrom

  • حالا می بایست با استفاده از دستور زیر cdrom را به سیستم Mount  نماییم

Mount  /dev/cdrom  /mnt/cdrom

  • با استفاده از دستور زیر فایل VMwareTools-version.tar.gz را به دایریکتوری موقت tmp  جهت اجرا کپی می نماییم

cp  /mnt/cdrom/VMwareTools-version.tar.gz /tmp/

  • برای مشخص کردن نسخه Vmware Tools دستور زیر را اجرا می نماییم

ls /mnt/cdrom

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

# VMwareTools-5.0.0-12124.tar.gz

  • به دایریکتوری مربوط به tmp وارد شده و با استفاده از دستور زیر tar محتویات فایل vmware-tools-distrib را استخراج می نماییم ( Extract )

Cd /tmp
tar -zxvf  VMwareTools-version.tar.gz

  • پس از Extract کردن به دایریکتوری vmware-tools-distrib  رفته و دستور زیر را جهت نصب Vmware Tools  اجرا می نماییم

cd vmware-tools-distrib
./vmware-install.pl

  • بعد از اجرای دستور فوق سیستم برای نصب Vmware Tools بر روی ماشین مورد نظر اماده شده و پیغام هایی ظاهر می شود که تنها نیاز به وارد کردن کلید Enter می باشد.

در انتهای کار به شما پیغام نصب موفقیت آمیز Vmware Tools  را نشان می دهد

VMware Tools successfully

  • در صورت استفاده از محیط گرافیکی لینوکس می بایست جهت کارکرد صحیح Mouse و همچنین تغییر گرافیک دستگاه X Windows را ریستارت نماییم سپس دستور زیر را وارد می نماییم

/usr/bin/vmware-toolbox

  • براساس محیط سیستمی که شما از آن استفاده می نمایید شاید نیاز باشد cdrom را Umount  نمایید برای این کار از دستور زیر استفاده می نماییم :

umount /mnt/cdrom

  • در صورت نیاز به حذف Vmware Tools از ماشین مورد نظر به صورت زیر عمل می نماییم

cd
rm /tmp/VMwareTools-version.tar.gz
rm -rf /tmp/vmware-tools-distrib

در صورت استفاده از سیستم عامل لینوکس Redhat  و داشتن بسته RPM  برای نصب Vmware Tools تمامی مراحل مشابه بالا می باشد اما بطور کلی بصورت زیر عمل می نماییم :

  • mkdir /mnt/cdrom
  • mount /dev/cdrom /mnt/cdrom
  • rpm -ivh /mnt/cdrom/VMwareTools-version.rpm
  • /usr/bin/vmware-config-tools.pl

 

VEEAM PROXY SERVER

/۰ دیدگاه /در , , /توسط

VEEAM PROXY SERVER

Proxy Server یک جزء از ساختار Veeam Backup است که بین سرور پشتیبان و دیگر اجزای زیرساخت پشتیبان قرار می گیرد. در حالی که سرور پشتیبان مدیریت وظایف را انجام می دهد، پروکسی پردازش Jobها و ترافیک پشتیبان را ارائه می دهد.

وظایف Backup Proxy به شرح ذیل می باشد:

  • بازیابی اطلاعات ماشین مجازی از Repository
  • Compression
  • Deduplication
  • Encryption
  • انجام کلیه امور پشتیبان گیری با مدیریت Veeam Server

حالت های انتقال داده توسط Backup Proxy

  • Direct Storage Access
  • Virtual Appliance
  • Network

نصب Backup Proxy mannligapotek.com

بصورت پیش فرض نقش Backup Proxy هنگام نصب Veeam Backup  ،توسط خود سرور انجام می شود اما برای پشتیبان گیری در سایزهای بزرگ توصیه می شود حتما از سرور جداگانه ای با نقش Proxy Server  استفاده شود.

استفاده از Backup proxy باعث افزایش کارایی و بهبود عملکرد سرور Veeam می شود لذا در یک مجموعه بزرگ می توان از چندین سرور Backup Proxy استفاده نمود که بار کار بین سرور ها توزیع می گردد.

برای راه اندازی Backup Proxy لازم است که یک سرور با سیستم عامل ویندوز به Veeam Server اضافه گردد تا نقش Proxy Server برای آن به صورت کاملا اتوماتیک ایجاد گردد.برای استفاده از نقش Backup Proxy باید دو سرویس ویندوزی کاملا سبک Veeam Installer Service و Veeam Data Moverاجرا گردد.

حداقل ریسورس مورد نیاز Backup Proxy :

  • modern x86 processor with minimum of 2 cores
  • ۲ GB RAM
  • Disk Space: ۳۰۰ MB
  • Network: ۱ Gbps or faster
  • ۳۲-bit and 64-bit versions of the Microsoft operating systems

نکته : نقش Backup Proxy  میتواند برای سروری با ماهیت مجازی و یا فیزیکی ایجاد گردد.

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

–        دسترسی مستقیم Backup Proxy به ذخیره سازی که در آن VM ها ذخیره شده  باشد یا ذخیره سازی که در آن داده VM نوشته شده است. به این ترتیب، Backup Proxy، داده ها را مستقیما از Repository بازیابی خواهد کرد و اصطلاحاLAN را Bypass می نماید

  • سرور Proxy می تواند یک ماشین مجازی با دسترسی به دیسک ماشین های دیگر بر روی DataStore باشد که این روش هم کاملا LAN-Free عمل می نماید.

–        اگر هیچ یک از سناریوهای فوق امکان پذیر نیست، می توانید نقش Backup Proxy را به یک ماشین در شبکه، نزدیک تر به منبع یا ذخیره ساز متصل به Backup proxy اختصاص دهید. در این مورد، داده VM با استفاده از پروتکل NBD از طریق LAN انتقال خواهد یافت

توصیه های ESXI در خصوص SAN Multipathing

/۰ دیدگاه /در , /توسط

توصیه های 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

/۰ دیدگاه /در , , /توسط

رمز نگاری بکاپ ها در نرم افزار (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

قابلیت موجود در 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 تقریبا بتواند در بیشتر موارد کار را به درستی انجام دهد.

ایجاد VAPP

/۰ دیدگاه /در , /توسط

ایجاد VAPP

در این بخش شما با موارد زیر آشنا می شوید :

  • توصیف یک vApp
  • ایجاد یک vApp
  • استفاده از vApp برای مدیریت ماشین های مجازی
  • توسعه دادن و گرفتن خروجی از vApp ( Deploy And Export a vApp )

  • یک vApp یک Object در Vcenter Server Inventory می باشد
  • یک vApp یک Container برای یک یا چند ماشین مجازی می باشد
  • یک vApp می تواند برای Package  یا مدیریت برنامه های چند لایه ای استفاده شود.
  • شما می توانید یک vApp را روشن ، خاموش و یا از آن Clone تهیه نمایید
  • یک vApp می تواند بصورت OVF ( Open Virtualization Format ) یا OVA ( Open Virtualization Applience )

زمانی که شما یک ماشین مجازی را بصورت OVF می خواهید Export  کنید یک دایریکتوری از OVF File  و VMDK File  ها می باشد.

OVA چیست؟ pharmacieinde.com

یک OVA فرمتی از ماشین های مجازی قابل حمل  ( Portable Virtual Machine Format ) از XenSource  می باشد که یک محصول Third – Party   از شرکت Citrix می باشد.

یک OVA  یک فایل تک ( Single File ) مانند Zip File  می باشد که شامل همه فایل های مربوط به OVF  می باشد.

برای پیکربندی vAPP کافی است بر روی آن راست کلیک کنید و در قسمت EDIT  تنظیماتی مانند CPU And Memory Allocation  و IP Allocation Policy  را اعمال کنید.

شما می توانید پیکربندی VM Startup  و Shutdown Order  را انجام دهید.

 

در شکل بالا شما می توانید تفاوت های عملیات Export و Deploy  را بر روی vApps  مشاهده کنید.

Resouce : https://docs.vmware.com/en/VMware-vSphere/6.0

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

/۰ دیدگاه /در , /توسط

توصیه های عمومی ذخیره سازی 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 یا پورت آرایه ذخیره سازی باید از الگوریتم عمق صف استفاده کنند.