آرشیو تیر ماه 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 با توجه به ویژگی هایی که برای محیط مجازی ارائه نموده است می تواند یکی از بهترین انتخاب ها برای محیط مجازی باشد.

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 قرار می گیرند.

آشنایی با IPv6

آدرس IP شناسه ای یکتا برای مشخص شدن یک device در یک شبکه می­ باشد. یکتا بودن آدرس IP بدین معناست که آدرس IP یک device داخل شبکه­ ای که در آن قرار دارد فقط به آن سیستم اختصاص دارد . تا زمانی که یک device آدرس IP نداشته باشد نمی ­تواند با device های دیگر ارتباط برقرار کند .

آدرس­ های IP به دو دسته تقسیم می­ شوند . دسته­ ی اول IPv4 می­ باشد که اکثر ما با آن برخورد داشته ایم و تا حدودی با آن آشنا هستیم. آدرس­  IP  ورژن 4  یک آدرس 32 بیتی است که به صورت 4 عدد در مبنای ده که با نقطه از هم جدا شده اند، نمایش داده می­ شود (مانند : 192.168.1.1 ). این ورژن از IP به تعداد 2 به توان 32 آدرس را ارائه می­ کند. در حال حاضر بیش از 90 درصد آدرس­ ها در جهان  ، IPv4 می­ باشد.

از آنجایی که استفاده از پروتکل TCP/IP در سال­ های اخیر بیش از حد انتظار بوده، در آدرس دهی IPv4 ، محدود هستیم و آدرس­ های IPv4 رو به اتمام است. این یکی از دلایلی است که TCP/IP یک ورژن جدید از آدرس­ های  IP را طراحی کرد که با نام IPv6 شناخته می­ شود.

بعضی از مزیت­ هایی که IPv6  دارد :

• هزینه­ ی کمتر پردازشی : packet های IPv6 باز طراحی شده­ اند تا header های ساده ­تری را تولید و استفاده کنند که این موضوع فرایند پردازش packet ها توسط سیستم­ های فرستنده و گیرنده را بهبود می­ دهد.
• آدرس­ های IP بیشتر : IPv6 از ساختار آدرس دهی 128 بیتی استفاده می ­کند در حالی که IPv4 از ساختار آدرس دهی 32 بیتی استفاده می کند . این تعداد آدرس IP این اطمینان را می­ دهد که حتی بیشتر از آدرس­ های مورد نیاز در سال های آینده ، آدرس موجود است.
• Multicasting : در IPv6 از Multicasting به عنوان روش اصلی برقرار کردن ارتباط استفاده می شود. IPv6 بر خلاف IPv4 روش broadcast را ارائه نمی­ دهد. روش broadcast از پهنای باند شبکه به صورت غیر بهینه و نامناسب استفاده می­ کند.
• IPSec: پروتکل Internet Protocol Security)IPSec) در درون IPv4 وجود نداشت اما IPv4 از آن پشتیبانی می­ کرد در حالی که IPv6 این پروتکل را به صورت built in در درون خود دارد و می ­تواند تمامی ارتباطات را رمز گذاری (encrypt) کند.

آدرس دهی در IPv6

در IPv6 تغییرات عمده ­ای نسبت به IPv4 وجود دارد. IPv4 از ساختار آدرس دهی 32 بیتی استفاده می­ کند در حالی که IPv6 از ساختار آدرس دهی 128 بیتی استفاده می کند. این تغییر می تواند 2 به توان 128 آدرس یکتا را ارائه دهد . این میزان آدرس IP، پیشرفت بسیار زیادی را نسبت به تعداد آدرس IP که IPv4 ارائه می کند(2 به توان 32) دارد.

آدرس IPv6 دیگر از 4 بخش 8 بیتی استفاده نمی کند. آدرس  IPv6 به 8 قسمت 16 بیتی که هر قسمت ارقامی در مبنای 16 هستند و با (:) از هم جدا می شوند تقسیم می­شود. مانند:

65b3:b834:45a3:0000:0000:762e:0270:5224

در مورد آدرس ­های IPv6  یک سری نکته­ هایی وجود دارد که باید آنها را بدانید:

• این آدرس ها نسبت به بزگی حروف حساس نیستند
• صفر های سمت چپ هر بخش را میتوان حذف کرد
• بخش هایی که پشت سر هم صفر هستند را میتوان به صورت (::) خلاصه نویسی کرد (روی هر آدرس فقط یک بار می توان این کار را کرد)

مثال: آدرس loopback در IPv6 به صورت زیر است :

0000:0000:0000:0000:0000:0000:0000:0001

از آنجایی که می توان صفرهای سمت چپ هر بخش را حذف کرد آدرس را بازنویسی می کنیم :

0:0:0:0:0:0:0:1

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

1::

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

0000:0000:45a3:0000:0000:0000:0270:5224

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

45a3::270:5224::

در این حالت مشخص نیست که هر سری چه تعداد صفر پشت سر هم داشته ایم ، پس بهتر است که آن سری که تعداد صفر های بیشتری پشت سر هم دارد را خلاصه نویسی کنید.

0:0:45a3::270:5224

ساختار آدرس دهی در IPv6 به کلی تغییر کرده است ، به طوری که 3 نوع آدرس وجود دارد :

• Unicast: آدرس Unicast برای ارتباطات یک به یک استفاده می شود.
• Multicast: آدرس Multicast برای ارسال data به سیستم های مختلف در یک لحظه استفاده می شود. آدرس های Multicast با پیشوند FF01 شروع می شوند. برای مثال FF01::1 برای ارسال اطلاعات به تمام node ها در شبکه استفاده می شود ، در حالی که FF01::2 برای ارسال اطلاعات به تمام روترهای داخل شبکه استفاده می شود.
• Anycast: آدرس Anycast برای گروهی از سیستم ها که سرویسی را ارائه می کنند استفاده می شود.

توجه کنید که آدرس broadcast در IPv6  وجود ندارد.

آدرس های Unicast خود به سه دسته تقسیم می شود :

• Global unicast: آدرس های Global unicast ، آدرس های public در IPv6 می­باشد و قابلیت مسیریابی در اینترنت دارد. این آدرس ها معادل آدرس های public در IPv4 می باشد.
• Site-local unicast: آدرس های Site-local unicast ، آدرس های private هستند و مشابه آدرس های private در IPv4 می باشند و فقط برای ارتباطات داخل شبکه ای استفاده می شوند. این آدرس ها همیشه با پیشوند FEC0 شروع می شوند.
• Link-local unicast: آدرس های Link-local unicast مشابه APIPA در IPv4 هستند و فقط می توانند برای ارتباط با سیستمی که به آن متصل هستند ، استفاده شوند. این آدرس ها با پیشوند FE80 شروع می شود.

نکته دیگری که باید به آن اشاره کنیم ، IPv6 ازClassless Inter-Domain Routing (CIDR) که در سال های اخیر متداول شده اند( برای تغییر بخش net ID روی IPv4 )،استفاده می کند.برای مثال آدرس 2001:0db8:a385::1/48 بدین معناست که 48 بیت اول آدرس تشکیل دهنده ی net ID است.

IPv6 به 3 بخش تقسیم می شود:

• Network ID: معمولا 48 بیت اول آدرس تشکیل دهنده ی net ID آن می باشد. در آدرس های global address ، net ID توسط ISP به سازمان شما اختصاص داده می شود.
• Subnet ID: این بخش از 16 بیت تشکیل شده و با استفاده از آنها می توانید شبکه ی IPv6 خود را به subnet های مختلف تقسیم کنید. برای مثال شبکه ای با net ID 2001:ab34:cd56 /48 می تواند به دو زیرشبکه 2001:ab34:cd56:0001/64 و 2001:ab34:cd56:0002/64 تقسیم شود.
• (Unique Identifier(EUI-64: نیمه ی دوم آدرس (64 بیت آخر) را unique identifier می نامند، این بخش مشابه host ID در IPv4 است (یک سیستم را در شبکه مشخص می کند). این بخش تشکیل می شود از مک آدرس آن سیستم (48 بیت)که به دو قسمت تقسیم شده و عبارت FFFE که میان آن دو قسمت قرار می گیرد.

Auto configuration

یکی از مزیت های IPv6 قابلیت auto configuration است ، که در آن سیستم یک آدرس IPv6 برای خود انتخاب می کند ، سپس با ارسال پیام neighbor solicitation به آن آدرس بررسی میکند که این آدرس در شبکه برای سیستم دیگری استفاده نشده باشد. اگر این آدرس توسط سیستم دیگری استفاده شده باشد ،  به پیام جواب می دهد و سیستمی که قصد انتخاب آدرس را داشت متوجه می شود که از آن آدرس نمی تواند استفاده کند. قابل ذکر است احتمال اینکه یک آدرس به دو سیستم اختصاص داده شود خیلی کم است چون مک آدرس سیستم ها در آدرس دهی auto configuration استفاده می شود (مک آدرس یک آدرس یکتا است).

با توجه به تکنولوژی های پیش روی دنیای اطلاعات به  ویژه IOT یا اینترنت اشیاء که  به واسطه آن میتوان تعداد زیادی از اشیاء که در طول روز با آن ها سر و کار داریم (مانند سیستم های گرمایشی و سرمایشی، لوازم خانگی، ملزومات اداری و ...)، که به صورت هوشمند کنترل می شوند را با یکدیگر در بستر اینترنت ارتباط خواهند داشت. این امر بدین معناست که به میلیاردها آدرس IP نیاز خواهیم داشت و ملزم به استفاده از IPv6 می باشیم .

منبع : Faradsys.com

در این مقاله میخواهیم درباره آخرین نسخه از Vsphere نسخه 6.7 صحبت کنیم.

6.7 Vsphere توانایی های کلیدی را ارائه میکند که واحدهای فناوری اطلاعات را قادر می سازد تا به روند قابل توجه خواسته های جدید در عرصه فناوری اطلاعات در زیرساخت سازمان خود توجه کنند.

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

مدیریت ساده و کارآمد در مقیاس

Vsphere 6.7 بر اساس نوآوری های تکنولوژی به کار رفته در Vsphere 6.7 ساخته شده و  تجربه مشتری را به سطح کاملا جدیدی ارتقا داده است. سادگی مدیریت ، بهبود عملیاتی ، زمان عملکرد همه در یک مقیاس .

Vsphere 6.7 یک تجربه استثنائی برای کاربر با استفاده از vCenter Server Appliance) vCSA) به همراه دارد . این نسخه چندین APIs جدید را معرفی میکند که باعث بهبود کارایی و تجربه در راه اندازی vCenter ، راه اندازی چندین vCenter براساس یک قالب آماده میشود ، مدیریت vCenter Server Appliance و پشتیبان گیری و بازنشانی را به مراتب راحت تر میکند. همچنین به طور قابل توجهی توپولوژی vCenter Server را از طریق vCenter با embedded platform services controller را در حالت  enhanced linked ساده تر کرده است که مشتریان را قادر میسازد تا چند vCenter را به هم پیوند دهند تا دسترس پذیری بدون مرز را در سرار محیط بدون نیاز به external platform services controller یا  load balancers داشته باشند.

علاوه بر اینها ، با vSphere 6.7 vCSA بهبود عملکرد فوق العاده ای ارائه میشود . (تمام معیارها در مقایسه با vSphere 6.5 مقایسه شده است) :

• 2X faster performance in vCenter operations per second
• 3X reduction in memory usage
• 3X faster DRS-related operations (e.g. power-on virtual machine)

این بهبود عملکرد از داشتن تجربه کاربری سریع برای کاربران vSphere اطمینان حاصل میکند ، ارزش قابل توجه و همچنین صرفه جویی در وقت و هزینه در موارد استفاده متنوع همچون VDI ، Scale-out apps ، Big Data ، HPC ، DevOps  distributed cloud native apps و غیره دارد.

vSphere 6.7 بهبود هایی در مقایس و کارایی در زمان بروزرسانی ESXi هاست ها دارد. با حذف یکی از دو بار راه اندازی مجدد که به طور معمول برای ارتقاء نسخه اصلی مورد نیاز است ، زمان تعمیر و نگهداری را به طور قابل توجهی کاهش میدهد (Single Reboot) . علاوه بر آن Quick boot یک نوآوری جدید است که  ESXi hypervisor را بدون راه اندازی مجدد هاست فیزیکی ، و حذف زمان سپری شده برای بوت شدن ، از سر میگیرد.

یکی دیگر از مولفه های کلیدی vSphere 6.7 رابط کاربر گرافیکی است که تجربه ایی ساده و کارآمد را ارائه می دهد ،  می باشد. vSphere Client مبتنی بر HTML5 یک رابط کاربری مدرن ارائه میکند که پاسخگوی هر دو نیاز واکنشگرایی و سهولت در استفاده برای کاربر است. با vSphere 6.7 که شامل قابلیت های اضافه شده برای پشتیبانی از نه تنها جریان های کاری معمولی مشتریان ، بلکه سایر قابلیت های کلیدی مانند مدیریت NSX ، vSAN ، VUM و همچنین اجزای third-party است.

امنیت جامع Built-In

vSphere 6.7 بر روی قابلیت های امنیتی در vSphere 6.5 ایجاد شده و موقعیت منحصر به فرد آن را به عنوان hypervisor ارائه می دهد تا امنیت جامع را که از هسته شروع می شود، از طریق یک مدل مبتنی بر سیاست عملیاتی ساده هدایت کند.

vSphere 6.7 ابزارهای سخت افزاری Trusted Platform Module (TPM) 2.0 و همچنین Virtual TPM 2.0 را پشتیبانی می کند و به طور قابل توجهی امنیت و یکپارچگی را در hypervisor و سیستم عامل مهمان به همراه دارد.

این قابلیت از VM ها و هاست ها در برابر tampered شدن جلوگیری ، از بارگیری اجزای غیر مجاز ممانعت و ویژگی های امنیتی سیستم عامل مهمان را که توسط تیم های امنیتی درخواست شده فعال می کند.

رمزگذاری داده ها همراه با vSphere 6.5 معرفی شد و به خوبی جا افتاد. با vSphere 6.7 ، رمزگذاری VM بهبود بیشتری یافته و عملیات مدیریت را آسان تر کرده است. vSphere 6.7 جریان های کاری را برای رمزگذاری VM ساده می کند ، برای محافظت در داده ها در حالت سکون و جابجایی طراحی شده ، ساخت آن را به آسانی با یک راست کلیک و همچنین افزایش امنیت وضعیت رمزگذاری VM و دادن کنترل بیشتری برای محافظت به کاربر در برابر دسترسی به داده های غیر مجاز میدهد.

vSphere 6.7 همچنین حفاظت از داده ها را در حرکت با فعال کردن vMotion رمزگذاری شده درinstances های مختلف vCenter و همچنین نسخه های مختلف ارائه میدهد ، ساده تر کردن عملیات migrations دیتاسنتر را ایمن میکند ، داده ها را در یک محیط (hybrid cloud  (between on-premises and public cloud ، و یا در سراسر دیتاسنتر ها با موقعیت های مختلف جغرافیای انتقال می دهد.

vSphere 6.7 از تمام رنج تکنولوژی ها و فن آوری های امنیتی مبتنی بر مجازی سازی مایکروسافت پشتیبانی می کند. این یک نتیجه همکاری نزدیک بین VMware و مایکروسافت است تا مطمئن شود ماشین های ویندوزی در vSphere از ویژگی های امنیتی in-guest  در حالی که همچنان در حال اجرا با عملکرد مناسب و امنیت در پلت فرم vSphere هستند ، پشتیبانی میکند.

vSphere 6.7 امنیت داخلی جامعی را ارائه میکند که قلب SDDC ایمن است ، که این ادغام عمیق و یکپارچه با سایر محصولات VMware مانند vSAN، NSX و vRealize Suite برای ارائه یک مدل کامل امنیتی برای مرکز داده است.

Universal Application Platform

vSphere 6.7 یک پلتفرم کاربردی عمومی است که ظرفیت های کاری جدید مانند (تصاویر گرافیکی 3 بعدی، اطلاعات حجیم، HPC، یادگیری ماشینی، (In-Memory و Cloud-Native) را به خوبی mission critical applications موجود ، پشتیبانی میکند. همچنین برخی از آخرین نوآوری های سخت افزاری در صنعت را پشتیبانی میکند و عملکرد استثنایی را برای انواع کار های مختلف ارائه میدهد.

vSphere 6.7 پشتیبانی و قابلیت های معرفی شده برای GPU را از طریق همکاری VMware  و Nvidia ، با مجازی سازی GPUهای Nvidia حتی برای non-VDI و موارد غیر محاسباتی مانند هوش مصنوعی ، یادگیری ماشینی، داده های حجیم و موارد دیگر افزایش میدهد.

با پیشرفت تکنولوژی به سمت  Nvidia GRID™ vGPU  در vSphere 6.7 ، به جای نیاز به خاموش کردن بارهای کاری بر روی GPUها ،مشتریان میتوانند به راحتی این ماشین ها را موقتا متوقف کنند و یا اینکه از سر گیرند، به این ترتیب مدیریت بهتر چرخه حیاط هاست ، و به طور قابل توجهی باعث کاهش اختلال برای کاربران نهایی میشود. Vmware همچنان با هدف ارائه تجربه کامل Vsphere  به GPU ها در نسخه های آینده در این زمینه سرمایه گذاری میکند.

vSphere 6.7 با افزودن پشتیبانی از نوآوری های کلیدی صنعت ، که آماده است تا تاثیر قابل توجهی بر چشم انداز، که حافظه پایدار است ، همچنان رهبری تکنولوژی Vmware و همکاری پربار با شرکای کلیدی خود را به نمایش میگذارد . با حافظه پایدار vSphere،  مشتریان با استفاده از ماژول های سخت افزاری پشتیبانی شده، مانند آنهایی که از Dell-EMC و HPE موجود هستند، می تواند آنها را به عنوان ذخیره سازی های فوق سریع با IOPS بالا، و یا به سیستم عامل مهمان به عنوان حافظه non-volatile  قرار دهند این به طور قابل توجهی عملکرد سیستم عامل را در برنامه ها برای کاربرد های مختلف ، افزایش میدهد و برنامه ای موجود را سریعتر و کارآمدتر میکند و مشتریان را قادر میسازد تا برنامه های با عملکرد بالا بسازند که میتواند از حافظه مداوم vSphere استفاده کند.

شما میتوانید مجله Virtual Blocks Core Storage 6.7 را نیز ببینید که در آن اطلاعات بیشتری را در مورد استوریج جدید و ویژگی های شبکه ای مانند Native 4Kn disk support ، RDMA support و Intel VMD برای NVMe که بیشتر برنامه های سازمانی را در  vSphere اجرا میکند، مشاهده کنید.

تجربه Hybrid Cloud) Seamless Hybrid Cloud)

با پذیرش سریع vSphere-based public clouds از طریق شرکاری VMware Cloud Provider Program ، VMware Cloud در AWS، و همچنین دیگر ارائه دهندگان cloud  ، VMware متعهد به ارائه یک cloud  ترکیبی یکپارچه برای مشتریان است. vSphere 6.7 قابلیت vCenter Server Hybrid Linked Mode را معرفی میکند که آن را برای مشتریان به منظور داشتن نمایش پذیری unified و قابلیت مدیریتی on-premises محیط vSphere در حال اجرا بر روی یک نسخه و محیط vSphere-based public cloud ، مانند VMware Cloud در AWS، در حال اجرا بر روی نسخه های مختلف از vSphere را آسان و ساده کرده است. این قابیت از افزایش سرعت نوآوری و معرفی قابلیت های جدید در vSphere-based public clouds اطمینان حاصل میکند و مشتری را مجبور نمی کند تا به طور مداوم محیط محلی vSphere را به روز رسانی و ارتقا دهد.

vSphere 6.7 همچنین قابلیت Migration در حالت Cold وHot در محیط Cross-Cloud میدهد ، علاوه بر افزایش سهولت مدیریت ، تجربه seamless و non-disruptive hybrid cloud را ارائه میدهد. همانطور که ماشین های مجازی بین مراکز داده های مختلف مهاجرت می کنند ، یا از یک مرکز داده محلی به cloud  و بلعکس منتقل میشوند ، آنها احتمالا در میان انواع پردازنده های مختلف حرکت می کنند. vSphere 6.7 قابلیت جدیدی را فراهم می کند که کلیدی برای محیط های hybrid cloud است که به نام Per-VM EVC نامیده می شود. Per-VM EVC قابلیت EVC) Enhanced vMotion Compatibility) را به یک ویژگی ماشین تبدیل میکند ، که به جای استفاده از نسل خاصی از پردازنده که در cluster بوت شده ، از آن استفاده کند. این قابلیت seamless migration را در سراسر CPU های مختلف با حفظ حالت EVC در هر ماشین در طول migrations  در سراسر کلاستر ها اجازه میدهد.

پیش از این vSphere 6.0 قابلیت provisioning را بین vCenter instances معرفی کرده بود که اغلب به نام ” cross-vCenter provisioning ”  یاد می شود. استفاده از دو مورد vCenter این احتمال را می دهد که نمونه ها در نسخه های مختلف انتشار قرار داشته باشند. vSphere 6.7 مشتریان را قادر می سازد تا از نسخه های مختلف vCenter استفاده کنند، در حالی که اجازه می دهد cross-vCenter, عملیات provisioning مانند: (vMotion, Full Clone , cold migrate) را به طور یکپارچه ادامه دهد . این به خصوص برای مشتریانی که توانایی استفاده از VMware Cloud را در AWS به عنوان بخشی از hybrid cloud خود دارند، مفید است.