Преглед на лицензирането на сървър на Microsoft във виртуална среда

В края на миналата година публикувахме електронна книга за лицензиране на сървърни операционни системи на Microsoft във виртуална среда. Това беше последвано от уебинар от Томас Маурер и Андрю Сиревиче. Към края на тази сесия те отговориха на някои въпроси. Оттогава получихме още няколко. Ще използваме тази статия, за да отговорим на тези въпроси и да разширим допълнително някои от идеите в електронната книга.

Как работи лицензирането на ОС с Hyper-V Replica?

Начинът, по който лицензирането работи с Hyper-V Replica, беше разгледан в електронната книга и беше обсъден в уебинара, но все още е много често срещан въпрос тема. За съжаление, отговорът е много по-малко популярен. Репликите са действителни виртуални машини и не са същите виртуални машини като тези, които репликират. Следователно те трябва да бъдат лицензирани независимо от изходната виртуална машина. Лицензът, който сте закупили за изходната виртуална машина, не покрива репликата.

Разбира се, това е само най-основното обяснение. Както при всичко останало в лицензирането, винаги има ситуации, които не се удовлетворяват толкова лесно. За да започнете, репликите не трябва да бъдат лицензирани по точно същия метод като източника. Единственото изискване е те да са законно лицензирани. Това вероятно няма да означава много за повечето хора. Повечето инсталации, използващи Hyper-V Replica, вероятно репликират повечето, ако не и всички свои виртуални машини. Ако обаче сте някъде по средата или ако възпроизвеждате само няколко, това може да се окаже във ваша полза.

Лицензиране на базова реплика

Реплика алтернативен сценарий 1: Много гости на живо, по-малко реплики

Да приемем, че имате 20 виртуални машини, работещи с Windows Server на изходния хост. Вие решавате да закупите един лиценз за център за данни, за да ги покриете всички. Но вие искате да възпроизведете само две от тях. Въпреки че лицензът за център за данни за целевия хост със сигурност ще покрие тези две реплики, това е прекалено. Докато гостите използват стандартно издание (а не център за данни), можете да покриете и двата, като лицензирате целевия хост с един лиценз за стандартно издание. И така, простото разбиране е, че лицензите за реплики са обхванати при свои собствени условия и са независими от изходните виртуални машини.

Лицензиране на реплики: Много виртуални машини на живо с малко реплики

Реплика, алтернативен сценарий 2: Много изходни хостове, по-малко реплики

За предпочитане е да избягвам да използвам термина „реплика на хост“, защото наистина няма такова нещо. Всяка Hyper-V система може да хоства реплика и нищо не ви пречи да смесвате реплики и активни виртуални машини на един и същ хост. Ние обаче ще го използваме тук за удобство.

Да приемем, че сте изградили клъстер с пет хоста и имате няколко самостоятелни Hyper-V хоста. Вие сте проектирали сайт за възстановяване след бедствие с четири неклъстерирани хоста с по-ниска мощност. Те ще изпълняват всички едни и същи виртуални машини, но поради хардуерни разлики, с намален профил на производителност. За активния клъстер от пет възела трябва да се уверите, че всеки възел има достатъчно лицензи, за да изпълнява всички виртуални машини, които може да управлява по всяко време. Това може да е трудно за прогнозиране. Ако сте проектирали сайта за възстановяване след бедствие, така че неговите хостове да не са групирани, тогава имате много по-лесна работа. Тъй като имате по-малко хостове, почти естествено е, че няма да имате нужда от толкова много лицензи, дори ако използвате същия брой гости.

Много хостове се репликират към по-малко хостове

Реплика алтернатива 3: Софтуерна гаранция

Това беше споменато в оригиналния документ и в уебинара, но си струва да го повторите. Ако правото за виртуализация на изходната виртуална машина идва от лиценз, който включва софтуерна осигуровка, тогава не е необходимо да предоставяте отделно лицензиране за нейната реплика.

Реплика алтернатива 4: Настолни компютри и операционни системи, които не са на Microsoft

Трябва да повторим, че тази серия от лицензи се фокусира върху операционната система Windows Server като гост. Настолните версии на Windows във виртуална среда са разнообразни и сложни, но техните подходи за лицензиране винаги са различни от тези на Windows Server.

Що се отнася до операционните системи, които не са на Microsoft, това зависи изцяло от собственика на продукта. Ако това е дистрибуция на Linux, която не изисква закупен лиценз, тогава не е нужно да плащате на никого нищо. Ако това е друга операционна система или друга дистрибуция, за която трябва да платите в противен случай, тогава се консултирайте с този доставчик за техните правила. Microsoft няма никакви изисквания за лицензиране за тези операционни системи като реплики, както и за тях като активни виртуални машини.

Ами операционните системи Windows за настолни компютри?

Примерът в електронната книга за операционни системи за настолни компютри говори за една единствена опция, при която всяка виртуална машина изисква базов пълен пакетен лиценз и поне един друг лиценз за го направи напълно легален в среда на виртуална десктоп инфраструктура (VDI). За VDI компютърната система, използвана за достъп до виртуалното копие, също трябва да бъде правилно лицензирана. Това означава, че ще плащате за много лицензи за настолна операционна система Windows, ако искате да превърнете VDI в реалност.

Това обаче е само една опция. Сравнително скорошна промяна в лицензирането на Microsoft е лицензът за достъп до виртуален работен плот (VDA), който променя правилата в някои ситуации. В други може да използвате настолна операционна система във виртуална машина, но да не я използвате за VDI. След това има съвсем различни правила. Разбира се, може да се наложи да смесите и съпоставите, в зависимост от вашите точни нужди.

Изводът е, че настолните операционни системи Windows нямат опростен модел на лицензиране във виртуална среда, както го правят операционните системи Windows Server. Въпреки че винаги препоръчвам да говорите с акредитиран експерт по лицензиране на Microsoft за вашата ситуация, е наложително да го направите, когато става въпрос за настолни операционни системи. Има твърде много променливи и опции, за да направите лесен за следване документ, който ще пасне на всяка ситуация.

Как работят прехвърлянията на лицензи в ситуация на отказ на клъстер?

Обхванахме клъстерирането доста подробно в електронната книга и уебинара, но има и други ситуации, в които отказът може да играе роля. Например, какво ще стане, ако работите с десет виртуални машини на неклъстерна система и тя се провали? Е, лицензите, които не са OEM, могат да се прехвърлят, така че когато получите хардуер за смяна, просто вземете виртуалните машини на него и продължете както досега.

Ако това е само временна ситуация и възнамерявате да поправите изходния хардуер, можете да върнете виртуалните машини обратно към този хардуер без проблем. Това е така, защото 90-дневното ограничение за прехвърляне се отменя при случаи на хардуерен срив. Внимавайте да не злоупотребявате с това, тъй като отказът има за цел само да ви върне в състояние, сравнимо с тези преди отказ.

Извън случай на повреда, всяко прехвърляне на лиценз започва 90-дневен часовник. След като лицензът бъде прехвърлен към нова система, той не може да бъде законно преместен отново в продължение на 90 дни. Ето защо трябва напълно да лицензирате всеки хост в клъстер за максималния брой виртуални машини, които някога може да изпълнява, или рискувате да не отговаряте на изискванията.

Всичко това отнася ли се за Windows Server Foundation и Essentials?

Windows Server Foundation не може да изпълнява ролята на Hyper-V и въпреки че не мога да намеря нищо окончателно, изглежда, че не се поддържа и като гост. Предполагам, че ще работи, ако искате да направите нещо подобно. Изглежда, че Foundation не се покрива от по-старо издание от Windows Server Standard или Datacenter, което има смисъл, когато мислите за предназначението на Foundation.

Windows Server Essentials поддържа Hyper-V. Един лиценз на Essentials ви позволява да инсталирате Essentials на хоста и да стартирате едно виртуално копие на Essentials, при условие че не изпълнявате никакви други роли в хоста. Windows Server Essentials също не се покрива от правата за по-ниско издание.

Много въпроси включваха кои лицензионни ключове да се използват. Първото нещо, което трябва да запомните е, че лицензите са си лицензи и ключовете са си ключове. Тези термини не са взаимозаменяеми и имат само минимална връзка един с друг. Лицензите са споразуменията, които сключвате с Microsoft за законно използване на техния софтуер. Ключовете са буквено-цифровите знаци, които включвате, за да предпазите Windows Server от изключване.

Ключът, който въвеждате във всеки даден екземпляр на Windows Server, законно няма значение. Всеки даден ключ може да не е активиран или да е за друго издание, но освен това системата Windows Server ще го приеме. Докато сте законно лицензирани да управлявате екземпляра, в който сте поставили този ключ, нищо друго наистина няма значение. Ето защо всеки един екземпляр там под Автоматично активиране на виртуална машина използва същия ключ като всички останали.

Кой ключ трябва да използвате във всяка дадена ситуация зависи от версията и изданието на операционната система. Ако ще се премести на друг хост чрез Live Migration или експортиране/импортиране, не е необходимо да го въвеждате отново. Просто трябва да се уверите, че целевият хост има налично право за виртуализация.

Каква е истинската история за броя на физическите процесори?

Много проницателни читатели ни писаха, за да ни уведомят за грешка в електронната книга. Във втория пример казахме, че има 2 физически процесора, но картината показва 4 физически процесора. Това направи останалата част от примера трудна за разбиране. За да изясним това, картината беше правилна, но текстът не беше. След това коригирахме текста в електронната книга, така че не се колебайте да се върнете към оригиналната страница и да получите актуализирано копие.

Започвайки с Windows Server 2012 (предишните версии имаха различни правила), изданията Standard и Datacenter се лицензират за двойка физически процесори. Само за да не се бърка това с ядрата, по-лесният начин да мислите за това е, че лицензирането е чрез запълнен физически процесорен сокет. Така че, ако започнете със система с двоен процесор и искате да стартирате същия брой виртуални машини на система с четири процесора, вашите лицензионни разходи се удвояват, защото не можете да ограничите на кои физически гнезда ще работят виртуалните машини. В електронната книга сравнихме двойната 8-ядрена система в пример 1 с четириядрена 4-ядрена система в пример 2, за да покажем как бихте платили двойно лицензиране за същия брой ядра. Това е ефектът от лицензирането на чифт процесори.

Още въпроси?

Както винаги, препоръчвам ви да отправяте въпроси директно към вашия търговец на лицензи или към екипа за лицензиране на Microsoft. Целта на тези статии и презентации е да ви запознаят с основните концепции и да преодолеете някои от основните препятствия. Те не са предназначени да обяснят напълно всяка възможна ситуация.

Когато изпращате въпроси, имайте предвид, че говорим само за операционни системи на Microsoft във виртуална среда и се фокусираме върху сървърните платформи. Както казахме, конфигурациите за лицензиране на настолни операционни системи са твърде разнообразни, за да се покрият адекватно в общия смисъл. Софтуерните и сървърните приложения са далеч отвъд това, което можем разумно да покрием в блог, посветен на Hyper-V. За тях потърсете доставчика на приложението.

За въпроси, свързани със сървърни операционни системи на Microsoft във виртуална среда, се надяваме, че тези документи са предоставили достатъчно информация, за да започнете. Както обикновено, не се колебайте да ни оставите коментар или да ни изпратите имейл, ако нещо не е ясно!