close
تبلیغات در اینترنت
دیتا سنتر - 2

دیتا سنتر - 2

دیتا سنتر - 2

دیتا سنتر - 2
دیتا سنتر - 2
جایگاه شما !

معرفی SDS های شرکت HPE
همانطور که می دانید امروزه از SDDC ها استفاده می شود که باعث کاهش هزینه و افزایش سرعت پیاده سازی می شوند. یکی ار مهمترین تکنولوژیهایی که باید در SDDC ها استفاده شود، SDS می باشد (Software Defined Storage) . به عنوان مثال می توان VSAN را در Vmware به عنوان SDS نام برد. شرکت HPE نیز بدین منظور Store Virtual را معرفی می کند، که در دو مدل مختلف تولید و به بازار عرضه می شود.
در حالت اول Virtual Storage Appliance می باشد که روی مجازی سازی Hypervisor پیاده سازی می شود. برای راه اندازی این مدل باید لایسنس StorVirtual VSA خریداری شود.
در مدل دوم Converged Solution Appliance تولید می شود که یک سخت افزار اختصاصی به منظور راه اندازی SDS می باشد و دستگاههای StoreVirtual در این حوزه قرار می گیرند.به عنوان مثال در این زمینه می توان Converged System 250 را نام برد که پلتفرم این دستگاه Apollo 2000 می باشد.
این SDS ها مبتنی بر سیستم عامل Lefthand می باشند که همان SAN iQ نامیده می شود.
تکنولوژی SDS مناسب برای مجازی سازی دسکتاپ و مجازی سازی می باشد و بسیار مقیاس پذیر هستند و باعث افزایش سرعت پیاده سازی می شوند.

دوشنبه 22 مرداد 1397

Virtualization چیست؟

 

Virtualization (مجازی سازی) فرایند ایجاد یک نسخه مجازی از چیزی مانند نرم افزار، سرور، استوریج و شبکهاست. این فرایند موثرترین راه برای کاهش  هزینه های دنیای فناوری اطلاعات است در حالی که در تمام سطوح کارایی و بهره وری آن را افزایش می دهد.

مزایای مجازی سازی

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

  • کاهش هزینه های عملیاتی
  • Downtime ها را کاهش داده و یا از بین برده
  • افزایش بهره وری، کارایی و پاسخگویی دنیای IT
  • آماده سازی سریعتر برنامه ها و منابع
  • تداوم کسب و کار و بهبود بازیابی اطلاعات
  • ساده سازی مدیریت دیتا سنتر

مجازی سازی چگونه کار می کند؟

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

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

Virtual Machine

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

یک لایه نازک از نرم افزار به نام “hypervisor” ماشین های مجازی را از هاستی که روی آن نصب شده اند جدا می کند. hypervisor متناسب با نیاز هر ماشین و به صورت پویا، منابع پردازشی را به ماشین ها اختصاص می دهد.

 

کلمات کلیدی مربوط به مجازی سازی

ماشین های مجازی مشخصات زیر  را دارند که هر کدام فواید مختلفی را ارائه می کنند.

Partitioning

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

Isolation

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

Encapsulation

  • حالت کلی هر ماشین مجازی در فایل هایی ذخیره می شود
  • ماشین های مجازی به سادگی جابجایی فایل ها، انتقال می یابند

Hardware Independence

  • آماده سازی و جابجایی ماشین های مجازی به هر سروری

انواع مجازی سازی

 

مجازی سازی سرور

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

  • کارایی بهتر
  • کاهش هزینه عملیاتی
  • انجام سریع کار های سنگین
  • بهبود عملکرد برنامه ها
  • در دسترس بودن بالای سرور
  • از بین بردن پیچیدگی سرور و جلوگیری از بی مصرف ماندن سرور

مجازی سازی شبکه

مجازی سازی شبکه ساخت دوباره ی یک شبکه فیزیکی به صورت کامل و منطقی است. مجازی سازی شبکه این امکان را می دهد که برنامه ها دقیقا به همان صورت که در شبکه ی فیزیکی اجرا می شوند در یک شبکه مجازی اجرا شوند که فواید عملیاتی بهتر و استقلال سخت افزاری موجود در مجازی سازی را به همراه دارد. مجازی سازی شبکه، دستگاه ها و سرویس های شبکه را به صورت منطقی ارائه می کند (مانند سوئیچ، روتر، فایروال و vpn)

مجازی سازی دسکتاپ

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

مجازی سازی در مقابل CLOUD COMPUTING

اگرچه مجازی سازی و  Cloud Computing هر دو تکنولوژی های فوق العاده ای هستند اما نمی توان آن ها را به جای هم نام برد و استفاده کرد. مجازی سازی یک راهکار نرم افزاری است که محیط محاسبات پردازشی را از زیرساخت های فیزیکی مستقل می کند، در حالی که Cloud Computing سرویسی است که با دریافت تقاضا منابع محاسباتی به اشتراک گذاشته (مانند نرم افزار یا اطلاعات) را از طریق اینترنت در دسترس دریافت کننده ی سرویس قرار می دهد. به عنوان یک راه حل تکمیلی، سازمان ها می توانند با مجازی سازی سرور های خود شروع کنند، سپس به سمت استفاده از Cloud Computing حرکت کنند تا کارایی بهتر و سرویس بهینه تری را داشته باشند.

سه شنبه 16 مرداد 1397

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

کلیک کنید.

منبع : Faradsys.com

سه شنبه 16 مرداد 1397

معرفی پردازنده های EPYC که بر روی سرور های HPE DL385 G10 استفاده می شود.

این پردازنده ها نسبت به پردازنده های قدیمی تر 122 برابر پهنای باند بیشتری را برای Memory پوشش می دهند و 60 برابر I/O بیشتری را Support می کنند و تا 45 برابر هسته های بیشتری نسبت به محصولات مشابه رقبای خود دارند. این پردازنده های طراحی شده و بهینه شده برای مجازی سازی و Cloud می باشند. این پردازنده ها می توانند تا 32 هسته داشته باشند، تا 2 ترابایت RAM را در 8 کانال مجزا پوشش می دهند و برای اسلات های PCIe هم 128 لاین دارند. همچنین از مزیت های دیگر آنها این است که دارای یک سیستم امنیتی یکپارچه هستند که باعث محافظت از پردازش ها خواهد شد.
این پردازنده های دارای مدل های زیر می باشند:
7601
7551
7501
7451
7401
7351
7301
7281
7251
که پایین ترین مدل آن یعنی 7251 دارای 8 هسته می باشد و مدل 7601 دارای 32 هسته می باشد .تمامی این پردازنده ها 2 ترابایت Memory را پوشش می دهند و توان مصرفی آنها نیز بسته به مدل بین 120 تا 180 وات می باشد. همچنین Cache آنها نیز بین 32 تا 64 مگا بایت می باشد. از مهمترین مزیت های این پردازنده این این است که فاقد Chipset هستند و در واقع تمامی موارد درون Chipset بصورت یکپارچه درآمده است که همان معنی SOC را می دهد. روی سرور DL385 G10 می توان 2 پردازنده قرار داد. این پردازنده ها همانطور که در بالا ذکر شد بسیار مناسب برای مجازی سازی سرور می باشد و باعث می شود50 درصد کاهش هزینه به ازای هر ماشین مجازی داشته باشیم.

سه شنبه 09 مرداد 1397

تعریف Hyper-Converged:
با توجه به افزایش سرعت IT امروزه بسیاری از سازمان ها نیاز به راه اندازی مجازی سازی و منابع پردازشی در زمان کمی دارند. منظور از Hyper-Converged استفاده از راه حلی می باشد که بتوان به سرعت منابع پردازشی، ذخیره سازی، شبکه ، مجازی سازی سرور ، مجازی سازی دسکتاپ ، مجازی سازی شبکه را در یک سازمان راه اندازی کرد. در واقع Hyper-converged تمامی موارد فوق را در یک دستگاه جمع آوری نموده است و بصورت Appliance در اختیار ما قرار می دهد و در مدت کمتر از 15 دقیقه می توانیم زیر ساخت های IT را در سازمان راه اندازی کنیم. شرکت HPE امروزه دستگاه 250 و 380 را برای hyper-converged می سازد و به بازار عرضه کرده است.

سه شنبه 09 مرداد 1397

حفاظت از سرور vCenter با VCHA

در مقالات قبل درباره ویژگی HA برای شما صحبت کردیم . اما VCHA قابلیتی است که وظیفه دیگری را برعهده دارد. این موضوع احتمالا یکی از مواردی است که بیشتر وقت خود را در هنگام صحبت با مشتریان صرف آن می کنید. قابلیت (vCenter High Availability (VCHA در نسخه vSphere 6.5 در نوامبر 2016 معرفی شد.

 

قبل از اینکه شروع کنیم چند نکته را باید در نظر داشته باشید .

  • قابلیت VCHA از 3 نود تشکیل شده است. (Active – Passive – Witness)
  • برای راه اندازی تنها به یک vCenter Server Instance License نیاز است.
  • از Tiny Deployment استفاده نکنید. (این مورد برای موارد آزمایشگاهی استفاده میکنند)
  • از هر دو حالت Embedded PSC و Extended PSC پشتیبانی میکند.
  • قابلیت VCHA با DR یکی نیست.

 

بسیار خب ، اولین اقدامی که باید صورت بگیرید ، گرفتن Clone ها میباشد . از نود Active به نود Passive و سپس Witness عملیات Clone گرفتن را طی میکینم. کاری که قبل از گرفتن Clone انجام میدهیم اضافه کردن یک Second Adapter میباشد . و همچنین Primary Adapter را داریم که Management Interface  نامیده میشود و شامل FQDN , IP , MAC Address میباشد. این  Adapter  ها همچنین در نود پسیو وجود دارد اما به صورت آفلاین ، تا تداخلی در شبکه ایجاد نشود و تنها زمانی که نود اکتیو Fail شود و نود پسیو به اکتیو تبدیل شود ، آنلاین میوشد.

هر سه Second Adapter یک شبکه Private که به آن VCHA Network  میگوییم تشکیل میدهند . این شبکه از  Management Network مجزا است و این 3 نود میتوانند آی پی داشته باشند تا با هم ارتباط داشته باشند . این ارتباط میتواند Layer3 یا Layer2 باشد.

سرور vCenter شامل یک دیتابیس و یک فایل سیستمی که حاوی تنظیمات ، گواهینامه ها و …. است . پس نیاز داریم این دو دسته از اطلاعات را به نود Passive منتقل کنیم ، درنتیجه به یک Replication نیاز است. برای Replicate دیتابیس از مکانیزم Sync و برای فایل سیستمی از مکانیزم Async استفاده میشود.

وقتی نود Active دچار یک  Failure شود ، اینترفیس نود Passive آنلاین میشود . از طریق ARP به شبکه اعلام میکند که از این لحظه به عنوان نود اکتیو عمل میکند و Ownership اطلاعات IP و MAC نود اکتیو را میگیرد .

بعد از این اتفاق ما دو انتخاب داریم :

  • نود Fail شده را Troubleshoot کنیم و دوباره نود را انلاین کنیم ،درنتیجه Replication به روال قبل ادامه میابد .
  • اما اگر نتوانیم دوباره آنرا اکتیو کنیم ، در تنظیمات VCHA میتوانیم ، در vCenter ماشین قبلی را حذف و نود جدید را دوباره Redeploy کنیم ، تمام این عملیات non-disruptive میباشد.

حال اگر نود Witness دچار Fail شود چه ؟

از دست دادن Witness برای vCenter Server Instance به صورت non-disruptive میباشد اما کلاستر در حالت Degraded State  میرود. پس برای اینکه کلاستر به صورت سلامت عمل کند هر 3 نود باید آنلاین و به صورت سالم وجود داشته باشند. و هرکدام از نود های Passive یا Witness مشکل داشته باشند ، کلاستر در حالت Degraded State میرود و در این حالت Automatic Failover از نود Active به Passive انجام نخواهد شد و این این امر به منظور جلوگیری از وجود دو نود فعال در کلاستر میباشد.

وقتی درمورد PSC و VCHA صحبت میکنیم ، ابتدا باید تصمیم بگیرید که آیا از Enhanced linked mode استفاده میکنید؟ اگر پاسخ شما مثبت است ، در نسخه 6.5 شما باید از External PSC استفاده کنید.

پس اگر از External PSC استفاده میکنیم ، به یک Load balancer نیاز داریم . دلیل این امر این است که وقتی VCHA داریم ، نود اکتیو به صورت مشخص به PSC متصل باشد ، وقتی PSC دچار مشکل شود ، ما باید به صورت دستی آنرا به PSC دیگر متصل کنیم وقتی اینکار را انجام دهیم ، مکانیزم Repoint به نود Passive ما Replicate نمیشود ، پس آن نود همچنان به PSC ای که Fail شده اشاره میکند . پس اگر نود Active Fail شود و نود Passive به Active تبدیل شود به مشکل برخواهیم خورد.

حالا سوال اصلی اینجاست ، چرا سرور vCenter را Highly available میکنیم اما Platform services controller را نه ؟!  با کمک روش ذکر شده در مثال بالا ما هر دو اینها را Highly available میکنیم و در آن زمان است یک راه حل کامل را ارائه کرده ایم.

در مقالات بعدی سعی خواهد شد مطالب عمیق تری درباره این ویژگی برای شما توضیح داده شود ، پس همراه ما باشید ….

سه شنبه 02 مرداد 1397

Spanning Tree Protocol

سوئیچ های سیسکو با استفاده از پروتکل STP، از به وجود آمدن loop در شبکه جلوگیری می کنند. در یک LAN که دارای مسیر های redundant می باشد، اگر پروتکل STP فعال نباشد، باعث به وجود آمدن یک loop نامحدود در شبکه می شود. اگر در همان LAN پروتکل STP را فعال کنید، سوئیچ ها برخی از پورت ها را بلاک می کنند و اجازه نمی دهند اطلاعات از آن پورت ها عبور کنند.


پروتکل STP با توجه به دو معیار پورت ها را برای بلاک کردن انتخاب می کند:
• تمامی deviceهای موجود در LAN بتوانند با هم ارتباط برقرار کنند. درواقع STP تعداد پورت های کمی را بلاک می کند تا LAN به چند بخش که نمی توانند با هم ارتباط برقرار کنند، تقسیم نشود.
• Frame ها بعد از مدتی drop می شوند و به طور نامحدود در loop قرار نمی گیرند.
پروتکل STP تعادلی را در شبکه به وجود می آورد بطوریکه frame ها به هر کدام از device ها که لازم باشد می رسند بدون اینکه مشکلات loop به وجود آید.
پروتکل STP با چک کردن هر interface قبل از اینکه از طریق آن اطلاعات ارسال کند، از به وجود آمدن loop جلوگیری می کند. در این روند چک کردن اگر آن پورت داخل VLAN خود در وضعیت STP forwarding باشد، از آن پورت در حالت عادی استفاده می کند، اما اگر در وضعیت STP blocking باشد، ترافیک تمام کاربران را بلاک می کند و هیچ ترافیکی در آن VLAN را از آن پورت عبور نمی دهد.
توجه کنید که وضعیت STP یک پورت، اطلاعات دیگر مربوط به پورت را تغییر نمی دهد. برای مثال با تغییر وضعیت خود تغییری در وضعیت trunk/access و connected/notconnect ایجاد نمی کند. وضعیت STP یک مقدار جدا از وضعیت های قبلی دارد و اگر در حالت بلاک باشد پورت را از پایه غیر فعال می کند.

نیاز به پروتکل STP
پروتکل STP از وقوع سه مشکل رایج در LANهای Ethernet جلوگیری می کند. در نبود پروتکل STP ، بعضی از frame های Ethernet برای مدت زیادی (ساعت ها، روز ها و حتی برای همیشه اگر deviceهای LAN و لینک ها از کار نیوفتند) در یک loop داخل شبکه قرار می گیرند. سوئیچ های سیسکو به طور پیش فرض پروتکل STP را اجرا می کنند. توصیه می کنیم پروتکل STP را تا زمانی که تسلط کامل به آن ندارید، غیر فعال نکنید.

اگر یک frame درloop قرار بگیرد Broadcast storm به وجود می آید. Broadcast storm زمانی به وجود می آید که هر نوعی از frameهای Ethernet  (مانند multicast frame،broadcast frame و unicast frameهایی که مقصدشان مشخص نیست) در loop بی نهایت داخل LAN قرار بگیرند. Broadcast stormها می توانند لینک های شبکه را با کپی های به وجود آمده از یک frame اشباع کنند و باعث از بین رفتن frameهای مفید شوند، و نیز با توجه به بار پردازشی مورد نیاز برای پردازش broadcast frameها، تاثیر قابل ملاحظه ای روی عملکرد deviceهای کاربران دارند.
تصویر 1-2 یک مثال ساده از Broadcast storm را نشان می دهد که در آن سیستمی که Bob نام دارد یک broadcast frame ارسال می کند. خط چین ها نحوه ارسال frameها توسط سوئیچ ها را در نبود STP نمایش می دهند.

 

در تصویر 1-2، frameها در جهت های مختلفی می چرخند، برای ساده تر شدن مثال فقط در یک جهت آنها را نمایش داده ایم.

در مفاهیم سوئیچ، سوئیچ ها در ارسال کردن broadcast farmeها، frameها را به تمام پورت ها به جز پورت فرستنده آن frame، ارسال می کنند. در تصویر 1-2، سوئیچ SW3، frame را به سوئیچ SW2 ارسال می کند، سوئیچ SW2 آن را برای سوئیچ SW1 ارسال می کند، سوئیچ SW1 نیز آن را برای SW3 ارسال می کند و به همین ترتیب این frame به سوئیچ SW2 ارسال می شود و داخل یک loop می چرخد.
زمانی که یک Broadcast storm اتفاق می افتد، frame ها مانند مثال بالا به چرخیدن ادامه می دهند تا زمانی که تغییراتی به وجود آید (شخصی یکی از پورت ها را خاموش کند، سوئیچ را reload کند یا کاری کند که loop از بین برود).
Broadcast storm همچنین باعث به وجود آمدن مشکل نا محسوسی به نام MAC table instability یا ناپیوستگی جدول مک می شود. MAC table instability بدین معنا است که جدول مک آدرس پیوسته در حال تغییر کردن می باشد، و علت آن این است کهframe هایی با مک آدرس یکسان از پورت های مختلفی وارد سوئیچ ها می شوند. به مثال زیر توجه کنید:
در تصویر 1-2 در ابتدا سوئیچ SW3 مک آدرس باب را که از طریق پورت Fa0/13 وارد سوئیچ شده، به جدول مک آدرس خود اضافه می کند:
0200.3333.3333 Fa0/13 VLAN 1
حالا فرایند switch learning را در نظر بگیرید در زمانی که frame در حال چرخش از سوئیچSW3 به سوئیچ SW2 ، سپس به سوئیچ SW1 و بعد از آن از طریق پورت G0/1 وارد سوئیچ SW3 می شود. سوئیچ SW3 می بیند که مک آدرس مبداء 0200.3333.3333 می باشد و از پورت G0/1 وارد سوئیچ شده است، جدول مک آدرس خود را به روز می کند:
0200.3333.3333 G0/1 VLAN 1
در این مورد سوئیچ SW3 هم دیگر نمی تواند به درستی frameها را به مک آدرس باب برساند. اگر در این حالت یک frame (خارج از frameهایی که در داخل loop افتاده اند) به سوئیچ SW3 برسد که مقصد آن باب باشد، سوئیچ SW3 اشتباها frame را روی پورت G0/1 به سوئیچ SW1 ارسال می کند، که این موضوع ترافیک زیادی را به وجود می آورد.
سومین مشکلی که Frame های در حال چرخش در یک broadcast storm ایجاد می کنند این است که کپی های مختلفی از یک frame به دست گیرنده می رسد. در تصویر 1-2 فرض کنید که باب یک frame را برای لاری ارسال کند در حالی که هیچ کدام از سوئیچ ها مک آدرس لاری را نمی دانند. سوئیچ ها frameها را به صورت unicast هایی که مک آدرس مقصدشان مشخص نیست، ارسال می کنند. زمانی که باب یک frame که مک آدرس مقصدش لاری است را ارسال می کند، سوئیچSW3 یک کپی از آن را به سوئیچ های SW1 و SW2 ارسال می کند. سوئیچ های SW1 و SW2 نیز frame را broadcast می کنند، این کپی ها باعث می شود که آن frame در داخل یک loop قرار گیرد. سوئیچ SW1 همچنین یک کپی از frame را به پورت Fa0/11 برای لاری ارسال می کند. در نتیجه لاری کپی های مختلفی از آن frame را دریافت می کند، که می تواند باعث از کار افتادن برنامه ای در سیستم لاری و یا مشکلات شبکه ای شود.

جدول زیر خلاصه ای از سه مشکل اساسی در شبکه ای که دارای redundancy است و STP در آن اجرا نمی شود را نشان می دهد:

پروتکل (STP (IEEE 802.1D دقیقا چه کار می کند؟
پروتکلSTP با قرار دادن هر یک از پورت های سوئیچ در وضعیت های forwarding و blocking از به وجود آمدن loop جلوگیری می کند. پورت هایی که در وضعیت forwarding هستند به صورت عادی فعالیت می کنند، frameها را ارسال و دریافت می کنند. اما پورت هایی که در وضعیت blocking قرار دارند به جز پیام های مربوط به پروتکل STP (و برخی دیگر از پیام هایی که برای پروتکل ها استفاده می شوند) ، هیچ frame دیگری را پردازش نمی کنند. این پورت ها frameهای کاربران را ارسال نمی کنند، مک آدرس frameهای ورودی را ذخیره نمی کنند و frameهای دریافتی از کاربران را نیز پردازش نمی کنند.
تصویر 2-2 راه حل استفاده از پروتکل STP (قرار دادن یکی از پورت های سوئیچ SW3 در وضعیت blocking) در مثال پیشین را نمایش می دهد:

همانطور که در مراحل زیر نشان داده شده، زمانی که باب یک broadcast را ارسال می کند، دیگر loop به وجود نمی آید:
• مرحله اول: باب frame را به سوئیچ SW3 ارسال می کند.
• مرحله دوم: سوئیچ SW3 این frame را فقط به سوئیچ SW1 ارسال می کند، دیگر به سوئیچ SW2 ارسال نمی شود چون پورت G0/2 در وضعیت blocking قرار دارد.
• مرحله سوم: سوئیچ SW1 این frame را روی پورت های Fa0/12 و G0/1 ارسال می کند.
• مرحله چهارم: سوئیچ SW2 این frame را روی پورت های Fa0/12 و G0/1 ارسال می کند.
• مرحله پنجم: سوئیچ SW3 به صورت فیزیکی یک frame را دریافت می کند، اما frame دریافتی از SW2 را به دلیل اینکه پورت G0/2 در سوئیچ SW3 در وضعیت blocking قرار دارد، نادیده می گیرد.
با استفاده از توپولوژی STP در تصویر 2-2، سوئیچ ها از لینک موجود بین SW2 و SW3 برای انتقال ترافیک استفاده نمی کنند. با این حال، اگر لینک بین SW3 و SW1 دچار مشکل شود، پروتکل STP پورت G0/2 را از وضعیت blocking به وضعیت forwarding تغییر می دهد و سوئیچ ها می توانند از آن لینکredundant استفاده کنند. در این موقعیت ها پروتکل STP با انجام فرایند هایی متوجه تغییرات در توپولوژی شبکه می شود و تشخیص می دهد که پورت ها نیاز به تغییر در وضعیتشان دارند و وضعیت آن ها را تغییر می دهد.

سوالاتی که احتمالا زهن شما را نیز مشغول کرده: پروتکل STP چگونه پورت ها را برای تغییر وضعیت انتخاب می کند و چرا این کار را می کند؟ چگونه وضعیت blocking را برای بهره مندی از مزایای لینک های redundant، به وضعیت forwarding تغییر می دهد؟ در ادامه به این سوالات پاسخ خواهیم داد.
پروتکل STP چگونه کار می کند؟
الگوریتم STP یک درخت پوشا (spanning tree) از پورت هایی که frameها را ارسال می کنند تشکیل می دهد. این ساختار درختی، مسیرهایی را برای رسیدن لینک های ethernet به هم مشخص می کند. (مانند پیمودن یک درخت واقعی که از ریشه درخت شروع می شود و تا برگ ها ادامه دارد)
توجه: STP قبل از اینکه در سوئیچ های LAN استفاده شود، در Ethernet bridgeها به کار رفته بود.
STP از فرایندی که بعضا spanning-tree algorithm)STA) نامیده می شود، استفاده می کند که در آن پورت هایی که باید در وضعیت forwarding قرار بگیرند را انتخاب می کند. STP پورت هایی که برای forwarding انتخاب نشدند را در وضعیت blocking قرار می دهد. در واقع پروتکل STP پورت هایی که در ارسال کردن اطلاعات باید فعال باشند را انتخاب می کند و پورت های باقی مانده را در وضعیت blocking قرار می دهد.
پروتکل STP برای قرار دادن پورت ها در حالت forwarding از سه مرحله استفاده می کند:
• پروتکل STP یک سوئیچ را به عنوان root انتخاب می کند و تمام پورت های فعال در آن سوئیچ را در وضعیت forwarding قرار می دهد.
• در هر کدام از سوئیچ های nonroot (همه ی سوئیچ ها به جز root)، پورتی که کمترین هزینه را برای رسیدن به سوئیچ root دارد (root cost)، به عنوان root port(RP) انتخاب می کند و آن ها را در وضعیت forwarding قرار می دهد.
• تعداد زیادی سوئیچ می توانند به یک بخش از Ethernet متصل شوند، اما در شبکه های مدرن، معمولا دو سوئیچ به هر لینک (بخش) متصل می شوند. در بین سوئیچ هایی که به یک لینک مشترک متصل هستند، پورت سوئیچی که root cost کمتری دارد در وضعیت forwarding قرار می گیرد. این سوئیچ ها را designated switch می نامند و پورت هایی که در وضعیت forwarding قرار گرفته را designated port)DP) می نامند.
باقی پورت ها در وضعیت blocking قرار می گیرند.

خلاصه ای از علت قرار گرفتن پورت ها در وضعیت های blocking و forwarding توسط پورتکل STP

Bridge و Hello BPDU
فرایند STA با انتخاب یک سوئیچ به عنوان root شروع می شود. برای اینکه روند انتخاب را بهتر متوجه شوید، شما باید با مفهوم پیام هایی که بین سوئیچ ها تبادل می شود به خوبی آشنا شوید و با فرمت شناساگری که برای شناسایی هر سوئیچ استفاده می شود آشنا باشید.
(STP bridge ID (BID یک مقدار 8 بایتی برای شناسایی هر سوئیچ می باشد. Bridge ID به دو بخش 2 بایتی که مشخص کننده اولویت و حق تقدم است و 6 بایتی که system ID نامیده می شود و همان مک آدرس هر سوئیچ است، تقسیم می شود. استفاده از مک آدرس این اطمینان را می دهد که bridge ID هر سوئیچ یکتا خواهد بود.
پیام هایی که برای تبادل اطلاعات مربوط به پروتکل STP بین سوئیچ ها استفاده می شود، bridge protocol data units )BPDU) نام دارد. رایج ترین BPDU ، که hello BPDU نام دارد، تعدادی از اطلاعات که شامل BID سوئیچ ها نیز می شود را لیست می کند و ارسال می کند. با استفاده از BID درج شده روی هر پیام، سوئیچ ها می توانند تشخیص دهند که هر پیام Hello BPDU از طرف کدام سوئیچ است.
جدول زیر اطلاعات کلیدی مربوط به Hello BPDU را نشان می دهد:

انتخاب سوئیچ root
سوئیچ ها با استفاده از BIDهای موجود در پیام های BPDU، سوئیچ root را انتخاب می کنند. سوئیچی که عدد BID آن مقدار کمتری را داشته باشد به عنوان سوئیچ root انتخاب می شود. با توجه به اینکه بخش اول عدد BID مقدار اولویت می باشد، سوئیچی که مقدار اولویت پایین تری داشته باشد به عنوان سوئیچ root انتخاب می شود. برای مثال اگر سوئیچ های اول و دوم به ترتیب دارای اولویت های 4096 و 8192 باشند، بدون در نظر گرفتن مک آدرس سوئیچ ها که در به وجود آمدن BID هر سوئیچ موثر است، سوئیچ اول به عنوان سوئیچ root انتخاب خواهد شد.
اگر مقدار اولویت دو سوئیچ برابر شد، سوئیچی که مک آدرس آن مقدار کمتری را داشته باشد به عنوان سوئیچ root انتخاب می شود. در این حالت به علت یکتا بودن مک آدرس، حتما یک سوئیچ انتخاب خواهد شد. پس اگر مقدار اولویت دو سوئیچ برابر باشد و مک آدرس آنها 0200.0000.0000 و 0911.1111.1111 باشد، سوئیچی که دارای مک آدرس 0200.0000.0000 است، به عنوان سوئیچ root انتخاب می شود.
مقدار اولویت مضربی از 4096 است و به صورت پیش فرض برای همه ی سوئیچ ها مقدار 32768 را دارد. از آنجایی که مک آدرس سوئیچ ها معیار مناسبی برای انتخاب سوئیچ root نمی باشد بهتر است به صورت دستی مقدار اولویت را تغییر دهیم تا سوئیچی که می خواهیم به عنوان سوئیچ root انتخاب شود.
در فرایند انتخاب سوئیچ root، سوئیچ ها از طریق فرستادن پیام های Hello BPDU که BID خود را در این پیام ها به عنوان root BID قرار داده اند، سعی می کنند خود را به عنوان سوئیچ root به سوئیچ های مجاور خود معرفی کنند. اگر یک سوئیچ پیامی را دریافت کند که BID کمتری نسبت به BID خودش داشته باشد، آن سوئیچ دیگر خود را به عنوان سوئیچ root معرفی نمی کند، به جای آن شروع به ارسال پیام دریافتی که دارای BID بهتری است می کند (مانند رقابت های انتخاباتی که یک نامزد به نفع نامزد هم حزبش که موقعیت بهتری دارد، از رقابت در انتخابات خارج می شود). در نهایت تمامی سوئیچ ها به یک نظر نهایی می رسند که کدام سوئیچ BID کمتری دارد و همه آن سوئیچ را به عنوان سوئیچ root انتخاب می کنند.
توجه : در مقایسه دو پیام Hello با هم، پیامی که BID کمتری دارد، superior Hello و پیامی که BID بیشتری دارد، inferior Hello نام دارد.

تصویر 3-2 آغاز فرایند انتخاب سوئیچ root را نشان می دهد، در ابتدای این فرایند SW1 همانند باقی سوئیچ ها خود را به عنوان سوئیچ root معرفی می کند. SW2 پس از دریافت Hello مربوط به SW1 متوجه می شود که SW1 شرایط بهتری را برای root بودن دارد، پس شروع به ارسال Hello دریافتی از SW1 می کند. در این حالت سوئیچ SW1 خود را به عنوان root معرفی می کند و SW2 نیز با آن موافقت می کند اما سوئیچ SW3 هنوز سعی می کند که خود را به عنوان سوئیچ root معرفی کند و Hello BPDUهای خود را ارسال می کند.

دو نامزد هنوز باقی ماندند:SW1 و SW3. از آنجایی که SW1 مقدار BID کمتری دارد، SW3 پس از دریافت BPDU مربوط به SW1، SW1 را به عنوان سوئیچ root می پذیرد و به جای BPDU خود، BPDU دریافتی از SW1 را به سوئیچ های مجاور ارسال می کند.

پس از اینکه فرایند انتخاب تکمیل شد، فقط سوئیچ root به تولید پیام های Hello BPDU ادامه می دهد. سوئیچ های دیگر این پیام ها را دریافت می کنند و BID فرستنده و root costرا تغییر می دهند و به باقی پورت ها ارسال می کنند. در تصویر 4-2، در قدم اول سوئیچ SW1 پیام های Hello را ارسال می کند، در قدم دوم سوئیچ های SW2 و SW3 به صورت مستقل تغییرات را روی پیام های دریافتی اعمال می کنند و آن ها را روی پورت های خود ارسال می کنند.
برای اینکه بخواهیم مقایسه BID را خلاصه کنیم، BID را به بخش های تشکیل دهنده ان تقسیم می کنیم، سپس به صورت زیر مقایسه می کنیم:
• اولویتی که کمترین مقدار را دارد
• اگر مقدار اولویت آن ها برابر باشد، سوئیچی که مک ادرسش کمترین مقدار را دارد

انتخاب Root Port برای هر سوئیچ
در مرحله ی بعدی، پس از انتخاب سوئیچ root، پروتکل STP برای سوئیچ های nonroot (همه ی سوئیچ ها به جز سوئیچ root) یک root port )RP) انتخاب می کند. RP هر سوئیچ، پورتی است که کمترین هزینه را برای رسیدن به سوئیچ root دارد.
احتمالا عبارت هزینه برای همه ی ما در انتخاب مسیر بهتر، روشن و مشخص باشد. اگر به دیاگرام شبکه ای که در آن سوئیچ root و هزینه ارسال اطلاعات روی هر پورت مشخص باشد توجه کنید، می توانید هزینه برقراری ارتباط با سوئیچ root را برای هر پورت به دست آورید. توجه کنید که سوئیچ ها برای به دست آوردن هزینه برقراری ارتباط با سوئیچ root، از دیاگرام شبکه استفاده نمی کنند، صرفا استفاده از آن برای درک این موضوع به ما کمک می کند.
تصویر 5-2 همان سوئیچ های مثال پیشین که در آن سوئیچ root و هزینه ی رسیدن به سوئیچ root را برای پورت های سوئیچ SW3 نشان می دهد.

سوئیچ SW3 برای ارسال frameها به سوئیچ root، می تواند از دو مسیر استفاده کند: مسیر مستقیم که از پورت G0/1 خارج می شود و به سوئیچ root می رسد، و مسیر غیر مستقیمی که از پورت G0/2 خارج می شود و از طریق SW2 به سوئیچ root می رسد. برای هر یک از پورت ها، هزینه ی رسیدن به سوئیچ root برابر است با مجموع هزینه ی خروج از پورت هایی که frame ارسالی، برای رسیدن به سوئیچ root از آن ها عبور می کند (در این محاسبه، هزینه ورود آن frame به پورت ها حساب نمی شود). همانطور که مشاهده می کنید، مجموع هزینه ی مسیر مستقیم که از پورت G0/1 سوئیچ SW3 خارج می شود برابر 5 است، و مسیر دیگر دارای مجموع هزینه ی 8 می باشد. از آنجایی که پورت G0/1، بخشی از مسیری است که هزینه ی کمتری برای رسیدن به سوئیچ root دارد، سوئیچ SW3 این پورت را به عنوان root port انتخاب می کند.
سوئیچ ها با سپری کردن فرایندی متفاوت به همین نتیجه می رسند. آنها هزینه خروج از پورت خود را به root cost موجود در Hello BPDU ورودی از همان پورت اضافه می کنند و هزینه رسیدن به سوئیچ root از طریق آن پورت را به دست می آورند. هزینه خروج از هر پورت در پروتکل STP یک عدد صحیح (integer) می باشد که به هر پورت در هر VLAN اختصاص می یابد، تا پروتکل STP با استفاده از این مقیاس اندازه گیری بتواند تصمیم بگیرد که کدام پورت را به توپولوژی خود اضافه کند. در این فرایند سوئیچ ها، root cost سوئیچ های مجاور را که از طریق Hello BPDUهای دریافتی به دست می آورند، بررسی می کنند.

تصویر 6-2 یک مثالی از چگونگی محاسبه بهترین root cost و سپس انتخاب آن به عنوان root port را نشان می دهد. اگر به تصویر توجه کنید، خواهید دید که سوئیچ root پیام هایی(Hello) که root cost آن ها برابر صفر می باشد را ارسال می کند. هزینه رسیدن به سوئیچ root از طریق پورت های سوئیچ root برابر با صفر است.
در ادامه به سمت چپ تصویر توجه کنید که سوئیچ SW3، root cost دریافتی از طریق SW1 را (که برابر صفر است) با هزینه ی خروج از پورت G0/1 که آن Hello را دریافت کرده (5) جمع می کند و هزینه ارسال اطلاعات از طریق این پورت را به دست می آورد.
در سمت راست تصویر، سوئیچ SW2 متوجه شده که root cost آن برابر با 4 است. پس زمانی که SW2 یک Hello برای SW3 ارسال می کند، مقدار root cost آن را 4 قرار می دهد. در سمت دیگرهزینه ارسال اطلاعات از طریق پورت G0/2 در سوئیچ SW3 برابر 4 است، از اینرو سوئیچ SW3 این دو مقدار را با هم جمع می کند و به این نتیجه می رسد که هزینه ی رسیدن به سوئیچ root از طریق پورت G0/2 برابر 8 است.
با توجه به نتایج به دست آمده از آنجایی که پورت G0/1 نسبت به پورت G0/2 هزینه ی کمتری برای رسیدن به سوئیچ root دارد، پس سوئیچ SW3 پورت G0/1 را به عنوان RP انتخاب می کند. سوئیچ SW2 نیزبا گذراندن همین فرایند پورت G0/2 را به عنوان RP انتخاب می کند. سپس تمام سوئیچ ها، root port های خود را در وضعیت forwarding قرار می دهند.

 

انتخاب Designated Port در هر LAN segment (پورت کاندید)
پس از انتخاب سوئیچ root، در سوئیچ های nonroot، تمام root portها را مشخص کردیم و آنها را در وضعیت forwarding قرار دادیم. مرحله نهایی پروتکل STP برای تکمیل توپولوژی STP، انتخاب designated port در هر LAN segment است. در هر بخش(segment) از LAN، پورت سوئیچی که کمترین root cost را دارد و به آن بخش از LAN متصل است Designated port )DP) نامیده می شود. زمانی که یک سوئیچ nonroot می خواهد که یک Hello را ارسال کند، هزینه رسیدن به سوئیچ root را در root cost آن پیام قرار می دهد و ارسال می کند. دراینصورت پورت سوئیچی که کمترین هزینه را برای رسیدن به root دارد، در میان تمام سوئیچ هایی که به آن بخش متصل هستند، به عنوان DP در آن بخش شناخته می شود. در این مرحله اگر هزینه سوئیچ ها برای رسیدن به سوئیچ root برابر بود، پورت سوئیچی که BID کمتری دارد را به عنوان DP انتخاب می کنیم.
در تصویر 4-2 پورت G0/1 در سوئیچ SW2 که به سوئیچ SW3 متصل است، به عنوان DP انتخاب می شود.
پس از انتخاب DPها، تمام آن ها را در وضعیت forwarding قرار می دهیم.
مثالی که در تصاویر 3-2 تا 6-2 به نمایش گذاشته شد، تنها پورتی که نیازی ندارد تا در وضعیت forwarding قرار بگیرد، پورت G0/2 در سوئیچ SW3 است. درنهایت فرایند پروتکل STP کامل شد و جدول زیر وضعیت نهایی هر پورت و علت قرار گرفتن در آن وضعیت را نشان می دهد:

 

 

به صورت خلاصه اگر بخواهیم توضیح دهیم، در فرایند اجرای پروتکل STP:
• در قدم اول سوئیچ root انتخاب می شود که ابتدا تمام سوئیچ ها سعی می کنند خود را به عنوان root معرفی کنند، سپس سوئیچی که رقم BID آن مقدار کمتری را داشته باشد به عنوان سوئیچ root انتخاب خواهد شد.
• در قدم دوم برای هر سوئیچ، پورتی که کمترین هزینه برای رسیدن به سوئیچ root دارد را به عنوان root port انتخاب می شود. سپس همه ی root portها را در وضعیت forwarding قرار می گیرند.
• در قدم سوم پورت های کاندید انتخاب می شوند و در وضعیت forwarding قرار می گیرند. در نهایت پورت هایی که وضعیتشان مشخص نشده در وضعیت blocking قرار می گیرند.

شنبه 30 تير 1397

Veeam Backup & Replication یک برنامه پشتیبانی و محافظت از داده هاست که برای محیط های مجازی VMware vSphere و Microsoft Hyper-V hypervisors توسط شرکت Veeam ساخته شده است.این نرم افزار قابلیت پشتیبان گیری ، replication و Restore کردن ، برای ماشین های مجازی ارائه نموده است.
عملکرد:
Veeam Backup & Replication برای محیط های مجازی سازی شده طراحی گردیده است. به وسیله snapshots گرفتن از ماشین ها و استفاده از این snapshots برای گرفتن بکاپ که به دو صورت Full و Incremental است. برای بازگردانی داده ها می توان نسخه پشتیبان گرفته شده را در محل ذخیره شده قبلی یا در مکانی دیگر بازیابی نمود .

گرفتن Snapshots به وسیله VMware vSphere میتواند بار سنگینی بر عملکرد ماشین های مجازی بگذارد و مدیران IT را به چالش بکشد.Veeam به طرز چشمگیری این روند را بهبود بخشیده است.با استفاده از Snapshots گرفتن در سطح استوریج حتی در ساعات کاری با کمترین تاثییر بر عملکرد می توانید از داده های خود بکاپ تهیه نمایید.Veeam می تواند با ادغام با replication در سطح استوریج در صورتی که استوریج اصلی در دسترس نباشد و دچار مشکل شده باشد به سرعت داده شما را بازیابی نماید.

 

Storage partners for every business
در زیر لیست شرکت های تولید کننده استوریج که از Veeam Backup & Replication پشتیبانی نموده، آورده شده است. به وسیله این استوریج ها می توان سریع تر نسخه پشتیبانی از ماشین ها را تهیه نمود و سرعت باز گردانی اطلاعات را افزایش داد.

Recovery
نرم افزار veeam backup برای بازگردانی اطلاعات انتخاب های مختلفی را به کاربران ارائه می دهد.
Instant VM Recovery
به وسیله Instant VM Recovery کاربران veeam backup می توانند ماشین هایی که از آن بکاپ تهیه نموده اند را به سرعت در محل ذخیره بکاپ بالا بیاورند.

Full VM Recovery
به وسیله Full VM Recovery میتوانید آخرین وضعیت ماشین ها را در بازه های مشخص زمانی در هاست اصلی یا هاست دیگر، بازیابی نمایید. VM رامی توان در مکان اصلی که از آن بکاپ گرفته شده است ، در صورتی که آن ماشین خاموش باشد یا پاک شده باشد بازیابی نمود. و یا بازیابی در هاست جدید صورت گیرد که در این صورت تنظیمات ماشین باید قابل دسترسی باشد. (تنظیمات شبکه ، دیتا سنتر)
VM File Recovery
به وسیله Instant File-Level Recovery (IFLR) شما می توانید هر فایل مورد نظرتان را در بازه زمانی مشخص بازیابی نمایید. همچنین veeam از فایل سیستم های ویندوزی و لینوکسی پشتیبانی می نماید.

وحتی می توانید فایل های ماشین را مانند VMDK را بازگردانی نمایید.
Application-item recovery:
با استفاده از veeam backup می توانید به صورت مستقیم برای بازیابی Application های زیر استفاده نمایید.
Microsoft Active Directory

Microsoft Exchange
Microsoft SharePoint

Microsoft SQL Server


Oracle
با توجه به مختصر توضیحات بالا و با استناد به گزارش سال 2017 از Gartner ، veeam backup and replication توانسته جز 5 شرکت پیشرو در صنعت بکاپ و ریکاوری باشد.

در زیر نقاط قوت و ضعف آن را مشاهده می کنید که توسط Gartner اعلام شده است:
نقاط قوت:
Veeam قابلیت های بسیاری با گزینه های بازیابی ساده برای محیط VMware و Hyper-V ارائه نموده است.
برای چندمین سال پیاپی یکی از سریع ترین شرکت های در حال رشد در صنعت پشتیباتی بوده است.
نقاط ضعف:
بسیاری از مشتریان به این نکته اشاره کرده اند که سیاست قیمت گذاری لایسنس اغلب دیگر رقابتی نیست در حالی که مدیریت و ریکاوری در Veeam ساده می باشد. اندازه مناسب برای ذخیره سازی بکاپ و پیکربندی در مرحله نصب ممکن است توجه بیشتری نیاز داشته باشد زیرا نرخ تغییرات در ماشین های مجازی بسیار بالا می باشد.
Veeam فقط به طور رسمی اعلام نموده است که از سرور فیزیکی پشتیبانی می کند ولی هنوز به طور کامل این ویژگی را ادغام و اثبات ننموده است .
نتیجه گیری:
امروزه تداوم کسب و کار معنای جدیدی به خود گرفته است . زمانی که داده ها به عنوان منبع حیاتی کسب و کار شما است حفظ اطلاعات شما و اطمینان از صحت و در دسترس بودن آن یک اولویت است. به دلیل کاهش سرور های فیزیکی و افزایش ماشین های مجازی مدیران فناوری اطلاعات با یک سری جدید از مسائل محافظت از داده ها و چالش های پشتیبانی مواجه شده اند.این چیزی بیش از یک کپی از فایل های مهم است. وضعیت هر VM نیز باید محافظت شود و به راحتی قابل دسترس باشد. هر سازمان باید نیاز های بکاپ گیریش را در چهارچوب زیر ساخت مجازی مجددا ارزیابی نماید و سپس مناسب ترین فن اوری ها را برای ارائه بهتر محافظت از داده ها انتخاب کند. Veeam با توجه به ویژگی هایی که برای محیط مجازی ارائه نموده است می تواند یکی از بهترین انتخاب ها برای محیط مجازی باشد.

شنبه 30 تير 1397

با  منتشر شدن vSphere 6.7 به عموم مردم، طبیعی است که بحث های زیادی در اطراف ارتقا به آن وجود دارد. چگونه می توانیم ارتقا دهیم یا حتی چرا باید ارتقاء دهیم از سوالات پرطرفدار اخیرا بوده است. در این پست من این سؤالات و همچنین ملاحظاتی را که باید قبل از ارتقاء vSphere بررسی شود را پوشش خواهم داد. این ارتقاء دادن یک کار ترسناک یا غم انگیز نیست .

 

چرا ؟

خب بیاید با چرا شروع کنیم . چرا باید به vSphere 6.7 ارتقاء دهیم ؟ با VMware vSphere 6.7 سرمایه گذاری خود را در VMware تقویت می کنید. از آنجا که vSphere در قلب SDDC VMware قرار دارد ، ارائه و بنیاد ساختار اساسی برای استراتژی cloud  شما ارائه میکند ، ارتقاء دادن باید اولویت اصلی ذهن شما باشد اما تنها پس از دقت و توجه به ویژگی ها و مزایا و اینکه چگونه آنها را به نیازهای کسب و کار بر گردانید. شاید تیم های امنیتی برای یکپارچگی دقیق تر برای هر دو سیستم Hypervisor و سیستم عامل مهمان درخواست کرده باشد بنابراین استفاده از vSphere 6.7 و پشتیبانی از Trusted Platform Module (TPM) 2.0 یا Virtual TPM 2.0 اکنون مورد نیاز است. اگر امنیت نباشد ، شاید انعطاف پذیری برنامه ای در vSphere 6.7 که آن پیشرفت های تکنولوژی NVIDIA GRID ™ vGPU ، اجازه می دهد تا مشتریان قبل از vMotion آنرا را متوقف کند و از VM های فعال شده با vGPU خلاص شوند. صرف نظر از خود ویژگی ها، مهم این است که اطمینان حاصل شود ویژگی های مورد نیاز به طور مناسب به شرایط کسب و کار برمی گردند.

چرا

یکی دیگر از دلایل اینکه چرا باید ارتقاء پیدا کنیم به علت پایان پشتیبانی محصول یا کار آن است. اگر قبلا شنیده باشید، VMware vSphere 5.5 به سرعت به پایان عمر خود نزدیک می شود. تاریخ دقیق پایان کلی پشتیبانی برای vSphere 5.5  در روز 19 سپتامبر 2018 است. با در نظر داشتن این موضوع، ارتقاء باید در خط مقدم طرح های شما باشد. اما خبر خوب در مورد پایان سافتن vSphere 5.5 ، این است که VMware پشتیبانی عمومی از vSphere 6.5 را تا پنج سال کامل از تاریخ انتشار آن تا تاریخ 15 نوامبر 2021 گسترش داده است. اگر شما از من بپرسید این نکته بسیار شگفت انگیزی است. نقطه عطف بعدی درک چگونگی به ارتقاء به vSphere 6.5 /6.7 است که مشتریان را قادر می سازد تا مزایای یک راه حل نرم افزاری SDDC که کارآمد و امن است را داشته باشند .

 

چگونه

خب اجازه دهید در مورد چگونگی صحبت کنیم. چگونه ارتقا دهیم؟ برای شروع ، VMware انواع بسیاری از مستندات را برای کمک به نصب یا ارتقاء VMware vSphere با استفاده از VMware Docs فراهم می کند. سایت VMware Docs به رابط بسیار ساده تر که شامل قابلیت جستجو بهتر در نسخه ها و همچنین یک گزینه برای ذخیره اسناد در MyLibrary برای دسترسی سریع برای بعد به روز شده است . vSphere Central یک مخزن غظیم از منابع vSphere است از جمله وبلاگ ها، KB ها، فیلم ها، و walkthroughs ها که برای کمک به مشتریان است تا به سرعت اطلاعات مورد نیاز خود را پیدا کنند. بعدا، هر گونه راه حل VMware که با محیط شما مرتبط  باشد را بررسی کنید ، مانند مدیریت بازیابی سایت SRM)، Horizon View Composer) ، یا VMware NSX . قبل از شروع ، همچنین تعیین کنید که آیا تنظیم فعلی شما از معماری جاسازی شده یا خارجی برای SSO / PSC استفاده می کند، به این دلیل که ممکن است مسیر ارتقا شما را تحت تاثیر قرار دهد.

یک عامل کلیدی در کمک به اینکه چگونه به ارتقاء محیط vSphere بپردازد، بررسی در محدوده سازگاری های نسخه میباشد . همه نسخه های vSphere قادر به ارتقا به vSphere 6.7 نیستند. به عنوان مثال، vSphere 5.5 یک مسیر ارتقاء مستقیم را به vSphere 6.7 ندارد. اگر شما در حال حاضر vSphere 5.5 را اجرا می کنید، قبل از ارتقا به vSphere 6.7 ابتدا باید به vSphere 6.0 یا vSphere 6.5 ارتقا دهید. بنابراین قبل از اینکه شما به نصب جدیدترین نسخه vSphere 6.7 ISO خود بپردازید ، یکبار مسیر خود را اینجا انجام دهید و هر محیطی را که ممکن است در نسخه پایین تر از vSphere 6.0 اجرا کنید در نظر داشته باشید. قبل از شروع ارتقاء vSphere 6.7 ، این محیط قدیمی را به یک نسخه سازگار vSphere ارتقا دهید. پس از بحث درباره چگونگی ارتقاء، ما باید به طور طبیعی در مورد برنامه ریزی ارتقاء صحبت کنیم.

یادآوری:روش های پشتیبانی شده برای ارتقاء میزبان های vSphere شما عبارتند از: با استفاده از ESXi Installer، دستور ESXCLI از داخل (ESXi Shell، vSphere Update Manager (VUM و Auto Deploy.

برنامه ریزی

راز ارتقاء موفق با شروع برنامه ریزی شده است. ما درباره نحوه شروع آماده سازی برای ارتقاء vSphere با درک چگونگی و چرایی آن بحث کرده ایم. گام های منطقی بعدی شروع برنامه ریزی است. این جایی است که شما خود را در حال بررسی یافته ها در محیط خود و همچنین جمع آوری فایل های نصب و راه اندازی آنها برای ارتقاء. آماده میکنید .   بسیار مهم است  که ترتیب و مراحل سایر محصولات VMware را مشخص کنید بنابراین شما کاملا درک می کنید که باید قبل یا بعد از vCenter Server و ESXi باید چه کنید.   ارتقاء برخی محصولات غیرمجاز ممکن است نتایج بدی داشته باشد که می تواند یک مشکل را در برنامه ارتقاء شما قرار دهد. برای مشاهده جزئیات بیشتر با بررسی vSphere 6.7 Update Sequence KB Article شروع کنید. در طول برنامه ریزی مشتریان باید تمام محصولات ، نسخه ها و واحدهای تجاری را در نظر بگیرند که ممکن است در طول و یا بعد از ارتقاء تحت تاثیر قرارگیرند. برنامه ریزی باید شامل تست آزمایشگاهی ارتقا باشد تا اطمینان حاصل شود که روند و نتایج را درک کنید. انجام یک بررسی سلامتی vSphere ممکن است بهترین پیشنهادی باشد که میتوانم بدهم . ارزیابی vSphere می تواند به کشف منابع هدر رفته، مشکلات محیطی و حتی مواردی ساده مانند تنظیم نادرست NTP یا DNS کمک کند. در نهایت تمام اطلاعات محاسباتی ، ذخیره سازی  ، شبکه ایی و بک آپ های vendors را برای سازگاری با vSphere 6.7 جمع آوری کنید. هیچ چیز بدتر از آن نیست که بعد از ارتقاء محیط خود متوجه شوید که یک rd party vendor3 نسخه سازگار با vSphere را ارائه نکرده باشد.

ملاحظات ارتقاء

برای کمک بیشتر به مشتریان در ارتقاء vSphere ، من مجموعه کاملی از ملاحظات ارتقا را برای کمک به شما در شروع برنامه ارتقاء به vSphere 6.7. جمع آوری کرده ام.

ملاحظات vSphere

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

  • An Upgrade from vSphere 5.5 to vSphere 6.7 GA directly is currently not supported
  • vSphere 6.0 will be the minimum version that can be upgraded to vSphere 6.7
  • vSphere 6.7 is the final release that requires customers to specify SSO sites.
  • In vSphere 6.7, only TLS 1.2 is enabled by default. TLS 1.0 and TLS 1.1 are disabled by default.
  • Due to the changes done in VMFS6 metadata structures to make it 4K aligned, you cannot upgrade a VMFS5 datastore inline or offline to VMFS6, this stands true for vSphere 6.5 & vSphere 6.7. (See KB2147824)

ملاحظات سرور vCenter

(vCenter Server Appliance (VCSA  در حال حاضر به طور پیش فرض برای سرور vCenter استفاده می شود. vCenter Servers topology deployment   باید در مرکز برنامه ریزی ارتقاء vSphere شما باشد. چه از یک (external Platform Services Controller (PSC  یا embedded  استفاده کنید ، به یاد داشته باشید که توپولوژی را نمی توان در vSphere 6.0 یا 6.5 تغییر داد. اگر از vSphere 5.5 ارتقا می دهید ، تغییرات توپولوژی و ادغام SSO Domain Consolidation پشتیبانی می شود ، اما قبل از ارتقا به vSphere 6.x باید انجام شود.

  • The vSphere 6.7 release is the final release of vCenter Server for Windows. After this release, vCenter Server for Windows will not be available
  • vCenter Server 6.7 does not support host profiles with version less than 6.0 (See KB52932)
  • vCenter Server 6.7 supports Enhanced Linked Mode with an Embedded PSC (Greenfield deployments only)
  • If vCenter High Availability (VCHA) is in use within your vSphere 6.5 deployment, you must remove the VCHA configuration before attempting an upgrade.

 

معیارهای سازگاری محصولات VMware

گاهی اوقات با انتشار نرم افزارهای جدید، دیگر محصولاتی که بر پایه اجزای ارتقا یافته قرار دارند، ممکن است در روز از اول محصولات GA کاملا پشتیبانی نشوند یا سازگار نباشند. راهنمای سازگاری VMware باید یکی از اولین توقف های شما در طول  مسیر ارتقاء vSphere باشد. با استفاده از این راهنما ها مطمئن میشوید که اجزای شما و همچنین مسیر ارتقاء مورد نظر شما ، پشتیبانی می شود.

با این محصولات زیر در حال حاضر سازگار با vSphere 6.7 GA نیستند.

  • VMware Horizon
  • VMware NSX
  • VMware Integrated OpenStack (VIO)
  • VMware vSphere Integrated Containers (VIC)

ملاحظات سخت افزاری

ارتقاء vSphere نیز می تواند توسط سخت افزار ناسازگار متوقف شود . با توجه به این موضوع، قبل از ارتقاء ، بایستی BIOS سخت افزار و سازگاری پردازنده را بررسی و مشاهده کنید. برای مشاهده لیست کامل CPU های پشتیبانی نشده، مقالهvSphere 6.7 GA Release Notes  منتشر شده در بخشی تحت عنوان “Upgrades and Installations Disallowed for Unsupported CPUs“ را مرور کنید.

  • vSphere 6.7 no longer supports certain CPUs from AMD & Intel
  • These CPUs are currently supported in the vSphere 6.7 release, but they may not be supported in future vSphere releases;
    • Intel Xeon E3-1200 (SNB-DT)
    • Intel Xeon E7-2800/4800/8800 (WSM-EX)
  • Virtual machines that are compatible with ESX 3.x and later (hardware version 4) are supported with ESXi 6.7
  • Virtual machines that are compatible with ESX 2.x and later (hardware version 3) are not supported

سازگاری سخت افزار و نسخه hypervisor و سطح ماشین مجازی باید به عنوان بخشی از برنامه ریزی شما نیز در نظر گرفته شود. به یاد داشته باشید نسخه سخت افزاری VM اکنون به عنوان سازگاری VM شناخته می شود. توجه: ممکن است لازم باشد سازگاری ماشین مجازی را قبل از استفاده از آن در vSphere 6.7 ارتقا دهید.

 

جمع بندی

جهت یاد آوری باید خاطر نشان کنیم که بخش چرا و چگونه را با تمرکز و دقت بالا مطالعه کنید. بدون داشتن تمرکز بر اینکه چه چیزی ارتقاء را در شرایط رضایت بخش به ارمغان می آورد یا درک تمام مزایای یکپارچه، در حقیقت آنها به راحتی می توانند از بین بروند. برنامه ریزی بخش بسیار مهم در مسیر ارتقاء است و بدون برنامه ریزی ممگن است در سازگاری ورژن ها به مشکل بر بخورید. اجرا ؛ بدون داشتن تمرکز و درک ویژگی ها یا روش ها و همچنین برنامه ریزی پیاده سازی ارتقاء vSphere ، شما قادر نخواهید بود که با موفقیت این کار را انجام دهید.

پس به یاد داشته باشید : تمرکز، برنامه ریزی، اجرا !

منبع : Faradsys.com

سه شنبه 19 تير 1397

معرفی  vCenter Server 6.7

vSphere 6.7 معرفی شد ! و vCenter Server Appliance اکنون به صورت پیش فرض deploy میشود . این نسخه پر از پیشرفت های جدید برای vCenter Server Appliance در تمام زمینه ها است . اکنون مشتریان ابزارهای بیشتری برای کمک به مانیتورینگ دارند. vSphere Client) HTML5) پر از جریان های کاری جدید و نزدیک به ویژگی های آینده نگرانه است. معماری vCenter Server Appliance به سمت مدل پیاده سازی ساده تر حرکت می کند. همچنین File-Based backup درونی که با یک scheduler همراه است . و رابط گرافی کاربر vCenter Server Appliance که از تم Clarity پشتیبانی میکند . اینها فقط بخشی از ویژگی های جدید در vCenter Server Appliance 6.7 هستند .این مقاله به جزئیات بیشتری از پیشرفت های ذکر شده در بالا  وارد خواهد شد.

 

Lifecycle

Install

یکی از تغییرات مهم در vCenter Server Appliance، ساده سازی معماری است . در گذشته تمام سرویس های vCenter Server در یک instance قرار داشت . اکنون میتوانیم دقیقا همان کار را با vCenter Server Appliance 6.7 انجام دهیم . vCenter Server با Embedded PSC به همراه Enhanced Linked Mode ارائه میشود. بیایید نگاهی به مزایایی که این مدل پیاده سازی ارائه می دهد بیندازیم:

  • برای ایجاد high availability نیازی به load balancer نیست و به طور کامل از native vCenter Server High Availability پشتیبانی میکند .
  • حذف SSO Site boundary ، پیاده سازی را با انعطاف پذیری بیشتری همراه کرده است.
  • پشتیبانی از حداکثر مقیاس vSphere
  • میتوانید تا 15 دامنه برای استفاده از vSphere Single Sign-On اضافه کنید
  • تعداد گره ها را برای مدیریت و نگهداری کاهش می دهد

Migrate

vSphere 6.7 همچنین آخرین نسخه برای استفاده از vCenter Server برای ویندوز را داراست ، که در گذشته نبود. مشتریان می توانند با ابزار داخلی Migration Tool به vCenter Server Appliance مهاجرت کنند. در vSphere 6.7 می توانید نحوه وارد کردن داده های تاریخی و عملکرد را در هنگام Migrate انتخاب کنیم.

  • Deploy & import all data
  • Deploy & import data in the background

مشتریان همچنین زمان تخمین زده شده از مدت زمانی که طول میکشد تا Migrate انجام شود را میبینند . زمان تخمین زده شده بر اساس اندازه داده های تاریخی و عملکرد در محیط شما متفاوت است. در حالی که مشتریان میتوانند در زمان وارد کردن داده ها در پس زمینه عملیات را pause یا resume کنند . این قابلیت جدید در رابط مدیریت vSphere Appliance موجود است. یکی دیگر از بهبود ها پشتیبانی از پورت های custom در زمان عملیات Migrate است . مشتریانی که پورت پیش فرض Windows vCenter Server را تغیرداده اند دیگر مسدود نمیشوند.

 Upgrade

vSphere 6.7 فقط از upgrades یا migrations از vSphere 6.0 یا 6.5پشتیبانی میکند . vSphere 5.5 مسیر مستقیم بروزرسانی به vSphere 6.7 ندارد. مشتریانی با vSphere 5.5 باید ابتدا به vSphere 6.0  یا  6.5بروزرسانی کنند و بعد به vSphere 6.7 بروزرسانی انجام دهند . هم چنین vCenter Server 6.0  یا  6.5 که هاست ESXi 5.5 دارند نمیتوانند بروزرسانی یا migrations  انجام دهند ، تا زمانی که حداقل به نسخه ESXi 6.0 یا بالاتر بروز کنند .

یادآوری : vSphere 5.5 در تاریخ September 19, 2018. به پایان پشتیبانی general میرسد.

نظارت و مدیریت

سرمایه گذاری بسیاری جهت بهبود وضعیت Monitoring  در vCenter صورت گرفته است. ما شروع این بهبود را از VSphere 6.5 دیدیم و در VSphere 6.7 شاهد چندین پیشرفت جدید نیز می باشیم. بیاییم به پنل مدیریتی vSphere VAMI بر روی پورت 5480  متصل شویم. اولین چیزی که مشاهده می کنیم این است که VAMI به محیط کاربری Clarity آپدیت شده است. ما همچنین می بینیم که در مقایسه با vSphere 6.5 تعدادی تب جدید در پنل سمت چپ قرار گرفته است. یک تب اختصاصی برای مانیتورینگ قرار داده شده است، که در آن ما می توانیم میزان مصرف و وضعیت سی پی یو، رم، شبکه و Database ها را مشاهده نمائیم. بخش جدیدی در تب مانیتورینگ تحت عنوان Disks قرار داده شده است. مشتریان می توانند پارتیشن هر یک از دیسک های vCenter سرور، فضای باقیمانده و مصرف شده را مشاهده نمایند.

بکآپ های File-Based اولین بار در vSphere 6.5 در زیرمجموعه تب summary قرار گرفتند و اکنون تب مخصوص خود را دارند. اولین گزینه ی در دسترس در تب بکآپ تنظیم scheduler می باشد. مشتریان می توانند بکآپ های vCenter را برنامه ریزی زمانی نموده و انتخاب نمایند که چه تعداد بکاپ حفظ گردد. یک قسمت جدید دیگر در بکـاپ های File-Based ، Activities می باشد. هنگام که یک job بکآپ کامل می شود اطلاعات با جزییات این رویداد در قسمت Activity به عنوان گزارش قرار می گیرد. ما نمی توانیم بدون در نظر گرفتن Restore کردن در مورد بکآپ صحبت کنیم. روند کاری Restore ، اکنون شامل مرورگر آرشیو بکآپ ها می باشد. این مرورگر تمام بکاپ های شما بدون نیاز به دانستن مسیر های بکآپ نشان می دهد.

تب جدید دیگر Services می باشد که در VAMI قرار گرفته است. زمانی درون vSphere Web Client بود و اکنون در VAMIبرای عیب یابی out of band  هست . تمام سرویس های vCenter Server Appliance ، نوع راه اندازی، سلامت و وضعیت آنها در اینجا قابل مشاهده است . ما همچنین گزینه ای برای شروع، متوقف کردن و راه اندازی مجدد این سرویس ها در صورت نیاز داریم. در حالی که تب های Syslog و Update در VAMI جدید نیستند ، اما در این زمینه ها پیشرفت نیز وجود دارد. Syslog اکنون تا سه syslog forwarding targets پشتیبانی میکند. پیش از این vSphere 6.5 فقط از یکی پشتیبانی میکرد . اکنون انعطاف پذیری بیشتری در پچ کردن و به روز رسانی وجود دارد. از برگه Update، اکنون گزینه ای برای انتخاب اینکه کدام پچ یا به روز رسانی اعمال  شود وجود دارد. مشتریان همچنین اطلاعات بیشتری از جمله نوع ، سطح لزوم و همچنین در صورت نیاز به راه اندازی مجدد را مشاهده میکنند. با باز کردن پنجره نمایش پچ یا به روز رسانی ، اطلاعات بیشتر در مورد آنچه که شامل است نمایش داده خواهد شد و در نهایت ، اکنون می توانیم پچ یا به روز رسانی را از VAMI  نصب واجرا کنیم. این قابلیت قبلا تنها از طریق CLI در دسترس بود.

 

(vSphere client(HTML5

از ویژگی هایی  که در vSphere 6.7  روی آن سرمایه گذاری قابل توجه ای شده است VSphere client  میباشد. VMware با معرفی vSphere 6.5   نسخه vSphere Client (HTML5) را معرفی کرد که در vCenter server Application از قابلیت های جزئی برخوردار بود. تیم فنی vSphere  به سختی بر روی آن کار می کنند تا از ویژگی های بیشتری پشتیبانی نماید و بر اساس باز خورد مشتریان عملکرد و ویژگی آن بهبود چشم گیری یافته است. برخی از ویژگی های  جدیدی که  در نسخه vSphere client    به روز شده  شامل موارد زیر است:

  • vSphere Update Manager
  • Content Library
  • vSAN
  • Storage Policies
  • Host Profiles
  • vDS Topology Diagram
  • Licensing

بعضی از به روز رسانی هایی که در بالا ذکر شده دارای تمام ویژگی های عملکردی  نیست . VMware به روز رسانی های vSphere Client را ادامه خواهد داد تا با ارائه (patch/update) این موارد بهبود یابد.

اکنون در منوی مدیریت ، گزینه های PSC بین دو زبانه تقسیم می شوند. Certificate management دارای برگه خاص خود است و تمام تنظیمات مدیریتی دیگر زیر برگه configuration هستند.

CLI Tools

CLI در vCenter Server Appliance 6.7 نیز دارای برخی از پیشرفت های جدیدی است . اولین پیشرفت Repoint با استفاده cmsso-util است. در حالی که این یک ویژگی جدید نیست ، این قابلیت در vSphere 6.5 موجود نبود و در Vsphere 6.7 دوباره اجرایی شده است . ما در مورد vCenter Server Appliance که به صورت مجزا با SSO Vsphere  هست صحبت می کنیم.

کاربران  می توانند vCenter Server Appliance    خود را از طریق vSphere SSO domains  ، ریپوینت کنند. قابلیت Repoint  فقط از external deployments که vSphere 6.7 دارد پشتیبانی میکند . قابلیت Repoint داخلی ویژگی pre-check دارد که من ترجیح میدهم استفاده نکنم ! ویژگی pre-check دو دامنه SSO را با هم مقایسه میکند و لیست اختلافات آنها را در یک فایل JSON ذخیره میکند. این فرصتی است که هر یک از این اختلافات را قبل از اجرای domain repoint tool  حل کنید. ابزار repoint میتواند لایسنس ها ، تگ ها ، دسته بندی ها و permissions ها را از  یک دامنه vSphere SSO به دیگری منتقل کند .

یکی دیگر از بهبود های CLI ، استفاده از cli installer ، برای مدیریت lifecycle در vCenter Server Appliance است .

vCenter Server Appliance ISO معمولا با JSON template examples همراه است. این JSON templates راهی برای اطمینان از سازگاری در طول نصب، ارتقاء و migrate است . معمولا ما باید یک JSON template را از cli installer در همان زمان و به روش صحیح اجرا کنیم . این پیاده سازی دستی per-node در حال حاضر با عملیات دسته ای ، از گذشته باقی مانده است. به عملیات دسته ای چندین JSON templates می تواند به طور متوالی از یک دایرکتوری بدون مداخله اجرا شود. برای تایید الگوها در دایرکتوری که شامل توالی است از گزینه pre-checks  استفاده کنید.

جمع بندی

خب ، vCenter Server Appliance 6.7 اکنون استاندارد جدیدی برای اجرای vCenter Server است . ما سعی خواهیم کرد چند مورد از ویژگی های برجسته این نخسه را بررسی کنیم .

 

سه شنبه 19 تير 1397
تبلیغات
Rozblog.com رز بلاگ - متفاوت ترين سرويس سایت ساز
محل تبلیغات متنی شما
روزیکس | مرجع وبمسترها
موبایل اسکای مرجع موبایل
ورود به سایت
عضویت سریع
    نام کاربری :
    رمز عبور :
    تکرار رمز :
    ایمیل :
    نام اصلی :
    کد امنیتی : * کد امنیتیبارگزاری مجدد
آمار سایت
  • آمار مطالب
  • کل مطالب : 37
    کل نظرات : 0
  • آمار کاربران
  • افراد آنلاين : 1
    تعداد اعضا : 0
  • کاربران آنلاین
  • آمار بازدید
  • بازديد امروز : 25
    بازديد ديروز : 0
    بازديد کننده امروز : 5
    بازديد کننده ديروز : 0
    گوگل امروز : 0
    گوگل ديروز: 0
    بازديد هفته : 25
    بازديد ماه : 40
    بازديد سال : 446
    بازديد کلي : 446
  • اطلاعات شما
  • آي پي : 35.172.201.102
    مرورگر :
    سيستم عامل :