Ако сте нов в света на виртуализацията, конфигурацията на мрежата може да бъде една от най-трудните концепции за разбиране. Работата в мрежа също е различна в Hyper-V, отколкото в други хипервайзори, така че дори тези с дългогодишен опит могат да се спънат малко, когато срещнат Hyper-V за първи път. Тази статия ще започне с разглеждане на концептуалния дизайн на виртуална мрежа в Hyper-V, конфигурация и след това работа чрез най-добрите практики за внедряване.
Преди да започнете, може да е полезно да сте сигурни, че имате солидни познания за основите на Ethernet и TCP/IP мрежите като цяло. Няколко статии, които обясняват общи аспекти, започват с това обяснение на OSI модела.
Единственият най-важен компонент на работата в мрежа в Hyper-V е виртуалният комутатор. В този блог има задълбочена статия за Hyper-V Virtual Switch, но в името на тази статия ще ви дам основно въведение в концепцията, в рамките на по-голямата картина.
Ключът към разбирането е осъзнаването, че това наистина е превключвател, точно като физически превключвател. Той работи в слой 2 като посредник за виртуални комутационни портове. Той насочва пакети към MAC адреси. Той обработва VLAN маркиране. Той дори може да изпълнява някои задачи за качество на услугата (QoS). Освен това е отговорен за изолирането на мрежовия трафик към виртуалния адаптер, който трябва да го получава. Когато се визуализира, мрежовият комутатор Hyper-V трябва да се разглежда по същия начин като стандартен комутатор:
Следващата част от разбирането на виртуалния комутатор е как той взаимодейства с хоста. За да отворите тази дискусия, първо трябва да се запознаете с наличните типове виртуални превключватели.
Има три възможни режима за превключвателя Hyper-V: частен, вътрешен и публичен. Не ги бъркайте със схеми за IP адресиране или друга конфигурация на виртуална мрежа в различна технология.
Частният превключвател на Hyper-VЧастният превключвател позволява комуникации между виртуалните машини на неговия хост и нищо друго. Дори операционната система за управление няма право да участва. Този превключвател е чисто логичен и не използва никакъв физически адаптер по никакъв начин. „Лично“ в този смисъл не е свързано с частно IP адресиране. Можете мислено да мислите за това като за превключвател, който няма възможност да се свързва към други превключватели.
Вътрешен превключвател на Hyper-VВътрешният превключвател е подобен на частния превключвател с едно изключение: операционната система за управление може да има виртуален адаптер на този тип превключвател. Това позволява на операционната система за управление да комуникира директно с всички виртуални машини, които също имат виртуални адаптери на същия вътрешен комутатор. Подобно на частния превключвател, вътрешният превключвател няма никаква връзка с физически адаптер и следователно също не може да се свързва към друг превключвател.
Външен превключвател на Hyper-VТипът външен превключвател трябва да бъде свързан към физически адаптер. Той позволява комуникации между физическата мрежа и операционната система за управление и виртуалните адаптери на виртуални машини. Не бъркайте този тип превключвател с публични схеми за IP адресиране или нека името му подсказва, че трябва да бъде свързан към система с интернет. Можете да използвате същия диапазон от частни IP адреси за адаптерите на външен виртуален комутатор, който използвате във физическата мрежа, към която е свързан. Външен в тази употреба означава, че може да се свързва към системи, които са външни за Hyper-V хоста.
Част от това, което прави разбирането на външния виртуален превключвател изкуствено трудно, е начинът, по който са формулирани свързаните настройки. В графичния потребителски интерфейс на Hyper-V Manager е формулиран като Разрешаване на операционната система за управление да споделя този мрежов адаптер. В командлета New-VMSwitch на PowerShell има параметър AllowManagementOS, който не е по-добър, и неговото описание — Указва дали родителският дял (т.е. операционната система за управление) трябва да има достъп до физическия NIC, свързан с виртуалния превключвател, който трябва да бъде създаден. — влошава положението. Това, което изглежда се случва твърде често, е, че хората четат това и мислят за виртуалния комутатор и виртуалните адаптери по следния начин:
За съжаление, това изобщо не е точно представяне на стека на виртуалната мрежа на Hyper-V. След като виртуалният комутатор е свързан към физически адаптер, този адаптер вече не се използва за нищо друго. TCP/IP и повечето други елементи се премахват от него. Операционната система за управление просто не може да го „сподели“. Ако се опитате да свържете нещо друго към адаптера, е много вероятно да счупите виртуалния превключвател.
В интерес на истината операционната система за управление получава свой собствен виртуален мрежов адаптер. Това е, което се свързва с виртуалния превключвател. Този адаптер не е точно като адаптерите, свързани към виртуалните машини; не е толкова богат на функции. Въпреки това, това не е нищо подобно на действително споделяне на физическия адаптер по начина, който предполагат контролите. По-добър термин би бил „Свързване на операционната система за управление към виртуалния комутатор“. Това наистина правят настройките. Следното изображение е много по-точно изображение на случващото се:
Както можете да видите, виртуалният адаптер на операционната система за управление се третира по същия начин като този на адаптерите на виртуалните машини. Разбира се, винаги имате възможност да извадите един или повече физически адаптери от виртуалния комутатор. Те ще се използват от операционната система за управление както обикновено. Ако направите това, тогава не е задължително да „споделяте“ адаптера на виртуалния комутатор с операционната система за управление:
Считано от Windows Server 2012, обединяването на мрежови адаптери вече е естествена функция на операционната система Windows Server. Обединяването ви позволява да комбинирате два или повече адаптера в един логически комуникационен канал, за да разпределите мрежовия трафик. Hyper-V Server може също да обединява физически адаптери.
Когато се създаде обединен адаптер, отделните адаптери все още се появяват в Windows, но по начин, много подобен на виртуалния превключвател, вече не могат да бъдат обвързани с нищо освен с екипния протокол. Когато екипът е създаден, на операционната система се представя нов адаптер. Би било правилно да наречем този адаптер „виртуален“, тъй като той не съществува физически, но това може да доведе до объркване с виртуалните адаптери, използвани с виртуалния комутатор Hyper-V. По-често срещаните термини са екипен адаптер или логически адаптер, а понякога се използва и съкращението tNIC.
Тъй като екипирането не е централна функция или изискване на Hyper-V, то няма да бъде обсъждано подробно тук. Hyper-V използва естественото обединяване на адаптери за голям ефект и следователно трябва да се използва винаги, когато е възможно. Като общо правило трябва да изберете алгоритъма за динамично балансиране на натоварването, освен ако нямате ясно дефинирана първостепенна нужда; той съчетава най-добрите характеристики на алгоритмите Hyper-V Port и Transport Ports. Що се отнася до това дали да използвате независимия от превключвателя режим на екипиране или един от зависещите от превключвателя режими, това е по-задълбочена дискусия, която включва балансиране на целите ви спрямо възможностите на наличния ви хардуер. За много по-задълбочено разглеждане на темата за обединяване с Hyper-V, консултирайте се със следните статии в блога на Altaro:
[thrive_leads id=’17165′]
Мрежовата конвергенция просто означава, че множество типове трафик се комбинират в един комуникационен канал. До известна степен Hyper-V винаги прави това, тъй като няколко виртуални машини използват един и същ виртуален превключвател, следователно същия мрежов хардуер. Всичко това обаче технически може да бъде класифицирано под едно заглавие „трафик на виртуална машина“, така че не е съвсем конвергенция.
В Hyper-V пространството истинската конвергенция ще включва поне още една роля и ще включва поне два физически мрежови адаптера. Най-лесният начин да постигнете това е чрез обединяване на два или повече адаптера, както беше споменато в предходния раздел и след това създаване на виртуален превключвател върху екипния адаптер. Когато виртуалният превключвател е създаден, използвайте опцията „споделяне“ или PowerShell, за да създадете и виртуален адаптер за операционната система за управление. Ако този адаптер се използва за нещо в операционната система за управление, това се счита за конвергенция. Други възможни роли ще бъдат обсъдени по-късно.
Въпреки че най-често срещаната конвергенция обикновено свързва всички адаптери с еднаква скорост в един канал, това не е изискване. Можете да използвате един екип за трафик на виртуална машина и друг за операционната система за управление, ако желаете.
Клъстерирането при срив има свои собствени специални мрежови нужди и Hyper-V разширява тези изисквания допълнително. Всеки възел започва със същите изисквания като самостоятелна Hyper-V система: един адаптер за управление и виртуален комутатор. Клъстерът добавя необходимостта от трафик, свързан с клъстера, и миграция на живо.
Във версии преди 2012 г. единствената поддържана конфигурация изискваше всички тези роли да бъдат разделени в уникални гигабитови връзки. С подобренията, въведени през 2012 и 2012 R2, тези изисквания са много по-облекчени. Няма публикувани изисквания за новите версии (въпреки че може да се твърди, че изискванията за 2008 R2 никога не са били официално заменени, така че технически все още се прилагат). На практика се наблюдава, че е абсолютно необходимо да има поне два уникални клъстерни пътя, но останалите могат да се коригират нагоре или надолу в зависимост от вашите работни натоварвания.
Следното описва всяка роля и дава кратко описание на нейния трафик:
Управление: Тази роля ще носи целия трафик за архивиране на ниво хост и всички свързани с хост дейности за споделяне на файлове, като например достъп до или копиране на ISO изображения от отдалечена система. През други периоди тази роля обикновено не изпитва голямо натоварване от трафик. Типичното използване е за трафик за дистанционно управление, като RDP и WS-Man (PowerShell), които са много леки.Клъстерни комуникации: Всеки възел в клъстера непрекъснато комуникира с всички други възли в мрежест модел, за да гарантира, че клъстерът все още работи. Тази операция е известна като „сърцебиене“, въпреки че информацията за конфигурацията на мрежата също се търгува. Сърдечният трафик обикновено е много слаб, но е изключително чувствителен към латентност. Ако няма специална мрежа, тя може лесно да бъде удавена от други операции, като копия на големи файлове, което ще доведе до загуба на кворум на възлите и отказ на виртуални машини, въпреки че нищо технически не е наред.
Клъстерни споделени томове: CSV трафикът не е уникална роля; той пътува като част от стандартните клъстерни комуникации. Когато всичко е наред, CSV трафикът е сравнително минимален, предавайки само CSV метаданни информация между възлите. Ако CSV премине в режим на пренасочен достъп, тогава целият трафик към и от този CSV ще се обработва от възела собственик. Ако някой друг възел трябва да получи достъп до този CSV, той ще го направи през клъстерна мрежа. Клъстерът ще гарантира, че нормалните комуникации на клъстера, като сърдечния ритъм, няма да бъдат пожертвани, но всякакви борби за честотни ленти ще доведат до лоша работа на виртуалните машини – и евентуално до срив. Ако вашият клъстер не използва CSV, тогава този трафик не е проблем. Миграция на живо: Без ограничения, операцията на миграция на живо ще използва толкова честотна лента, колкото може. Типичната конфигурация осигурява специален адаптер за тази роля. При конвергентната мрежа изискването не е толкова строго. Трафик на виртуална машина: трафикът на VM е може би най-важният в клъстера, но също така не е прекалено тежък. Традиционният подход е да се отдели поне един адаптер за виртуалния превключвател.Докато наследените компилации просто ги разделят на уникални, специални гигабитови канали, сега имате повече опции на ваше разположение.
Клъстерните комуникации винаги са използвали SMB протокола. Протоколът SMB беше надграден значително през 2012 г. и сега има възможност за многоканален достъп. Тази функция автоматично ще преговаря между изходния и целевия хост и автоматично ще разпределя SMB трафика между всички налични адаптери.
Докато преди беше необходимо да се задават мрежи за клъстерни комуникации и след това да се променят заданията на показателите, за да се насочва трафикът, предпочитаният подход в 2012 R2 е просто да се обозначат две или повече мрежи като клъстерни мрежи. Хостовете автоматично ще балансират трафика.
Ако всички възли на клъстера са настроени да използват SMB за миграция на живо, тогава той ще се възползва от същите подобрения на SMB, които използват стандартните комуникации на клъстера. По този начин трафикът за управление, трафикът на клъстерните комуникации и миграцията на живо могат да се управляват само в две отделни мрежи вместо в две. Това е потенциално рисковано, особено ако се задейства режим на пренасочен достъп.
Чрез използването на конвергирани мрежи получавате значително повече опции с по-малко хардуер. SMB multichannel разделя трафика между отделни мрежи – тоест уникални подмрежи. Като използвате конвергентни мрежи, можете да създадете повече подмрежи, отколкото имате физически адаптери.
Това е особено удобно за 10GbE адаптери, тъй като малко хостове ще имат повече от два. Също така има своето място в 1GbE мрежи. Можете просто да комбинирате всички физически адаптери в един единствен голям екип и да създадете същия брой логически мрежи, които бихте имали за традиционна роля, но активирайте всяка от тях за клъстерни комуникации и Live Migration. По този начин SMB multichannel ще може автоматично да балансира натоварването на своите нужди. Не забравяйте, че дори при конвергентна мрежа е най-добре да не комбинирате всички роли в един виртуален или екипен адаптер. SMB multichannel изисква отделни подмрежи, за да изпълнява ролята си и обединяването балансира част от трафика според виртуалния адаптер.
Въпреки че загрижеността рядко се проявява, технически е възможно един тип трафик да погълне напълно обединен екип. Налични са редица опции за QoS (Quality of Service), за да се предотврати това. Можете специално да ограничите SMB трафика и/или трафика за миграция на живо и да зададете максимуми и минимуми на виртуални адаптери.
Преди да прекарате много време в проучване на тези опции, имайте предвид, че повечето внедрявания не изискват тази степен на контрол и ще работят перфектно с настройките по подразбиране. Hyper-V ще работи автоматично, за да поддържа баланс на трафика, който не заглушава напълно конкретен виртуален мрежов адаптер. Тъй като сложността на конфигурирането на QoS превишава предимствата му в типичната среда, тази тема няма да бъде изследвана в тази серия. Най-категоричната работа по темата е достъпна в TechNet.
Една критична концепция е, че клъстерните мрежи се дефинират от TCP/IP подмрежа. Клъстерната услуга ще открие всеки IP адрес и подмрежова маска на всеки възел. От тях той ще създаде мрежа за всяка уникална подмрежа, която открие. Ако някой възел има повече от един IP адрес в подмрежа, клъстерната услуга ще използва един и ще игнорира останалите, освен ако първият не бъде премахнат. Ако услугата намери мрежи, за които само някои възли имат IP адреси, мрежата ще бъде маркирана като разделена. Една мрежа също ще бъде маркирана като разделена, ако клъстерните комуникации са разрешени, но има проблеми с потока на трафик между възлите. Следната диаграма показва някои примерни мрежи и как клъстерирането ще ги открие.
На илюстрацията единствената валидна мрежа е клъстерна мрежа 2. Най-лошата е клъстерна мрежа 4. Поради начина, по който е конфигурирана подмрежата, тя се припокрива с всички други мрежи. Клъстерната услуга автоматично ще заключи адаптера на възел 2 с IP адрес 192.168.5.11 извън клъстерните комуникации и ще маркира мрежата като None, за да покаже, че е забранена за клъстерни комуникации.
Преди да изградите вашия клъстер, определете IP подмрежите, които ще използвате. Напълно приемливо е да създавате изцяло нови мрежи, ако е необходимо. За клъстерни комуникации възлите няма да комуникират умишлено с нищо друго освен с възлите в същия клъстер. Минималният брой уникални мрежи е две. Единият трябва да бъде маркиран, за да позволи комуникации на клиент и клъстер; това е мрежата за управление. Едната трябва да бъде маркирана, за да позволи клъстерни комуникации (клиентски комуникации по избор, но не се препоръчват). Допълнителни мрежи не са задължителни, но ще предоставят на клъстера възможността да създава допълнителни TCP потоци, които могат да помогнат с балансирането на натоварването между обединени адаптери.
Няма нито един „правилен“ начин за конфигуриране на мрежа в Hyper-V, както не съществува нито един „правилен“ начин за конфигуриране физическа мрежа. Този раздел ще разгледа редица най-добри практики и процедури, за да ви покаже как се правят нещата и да предостави насоки, когато е възможно. Най-добрият съвет, който всеки може да ви даде, е да не го премисляте. Много малко виртуални машини ще изискват голяма честотна лента на мрежата.
Има няколко най-добри практики, които да ви помогнат да вземете някои основни решения за конфигурация:
Конвергентната мрежа води до най-доброто общо разпределение на честотната лента. Изключително рядко е да има ситуация, в която една мрежова роля ще използва постоянно цяла гигабитова връзка. Като посветите един или повече адаптери на една роля, вие предотвратявате използването на този адаптер от която и да е друга роля, дори когато неговата роля на собственик е неактивна. Единичен TCP/IP поток може да използва само една физическа връзка. Едно от най-объркващите неща при екипирането, с което се сблъскват новодошлите, е, че комбинирането на множество връзки в един екип не означава автоматично, че целият трафик автоматично ще използва всички налични връзки. Това означава, че различните комуникационни потоци ще бъдат балансирани между наличните. Или, за да стане това по-ясно, имате нужда от поне четири различни комуникационни потока, за да използвате напълно четири адаптера в екип. Избягвайте да използвате iSCSI или SMB 3 директно с екипиране. Поддържа се и за двете, но е по-малко ефективен от използването на MPIO (за iSCSI) или многоканален SMB. Поддържа се да имате множество виртуални мрежови адаптери в екип, които са конфигурирани за iSCSI или SMB многоканален. Винаги обаче ще получавате най-добрата производителност за мрежово съхранение, като използвате необвързани адаптери, които не са обвързани с виртуален комутатор. Тази статия обяснява как да конфигурирате MPIO.Необходимите стъпки за създаване на екип бяха свързани по-рано, но ето отново връзката: https://www.altaro.com/hyper-v/how-to-set-up- native-teams-in-hyper-v-server-2012/.
Ако вашата система работи с GUI издание на Windows Server, можете да конфигурирате TCP/IP за всички адаптери, като използвате традиционните графични инструменти. За всички версии можете също да използвате sconfig.cmd за ръководен процес. Този раздел показва как да изпълнявате тези задачи с помощта на PowerShell. За да бъде материалът възможно най-кратък, няма да бъдат показани всички възможни опции. Обърнете се към уводната статия за PowerShell за помощ относно използването на откриване на възможностите на кратки команди с помощта на Get-Help и други инструменти.
Вижте състоянието на адаптера (и имената за използване в други кратки команди)
Get-NetAdapterПреименуване на физически или екипен адаптер
Rename-NetAdapter Name CurrentName NewName NewNameЗадаване на IP адрес на адаптер
New-NetIPAddress InterfaceAlias AdapterName IPAddress 192.168.20.20 PrefixLength 24Задаване на шлюз по подразбиране на адаптер
New-NetRoute InterfaceAlias AdapterName DestinationPrefix 0.0.0.0/0 NextHop 192.168.20.1Съвет: използвайте „Set-NetRoute“, за да направите промени, или „Remove-NetRoute“, за да се отървете от шлюз.
Задаване на адреси на DNS сървъри
Set-DNSClientServerAddresses InterfaceAlias AdapterName –ServerAddresses 192.168.20.5, 192.168.20.6Предотвратяване на регистрация на адаптер в DNS
Set-DnsClient InterfaceAlias AdapterName RegisterThisConnectionsAddress $falseЕдна последна опция, която може да искате да обмислите, е да зададете Jumbo Frames на вашите виртуални адаптери. Jumbo Frame е всеки TCP/IP пакет, който надвишава основния размер от 1514 байта. Най-често се използва за iSCSI връзки, но може да помогне малко и с трафика на SMB 3 и Live Migration. Изобщо не е полезен за трафик, пресичащ интернет, а повечето обикновени LAN трафик също нямат голяма полза от него. Ако искате да го използвате, следната публикация го обяснява подробно: https://www.altaro.com/hyper-v/how-to-adjust-mtu-jumbo-frames-on-hyper-v-and -windows-сървър-2012/. Тази конкретна статия е написана за 2012 г. Виртуалният превключвател в 2012 R2 има Jumbo Frames, активирани по подразбиране, така че трябва да следвате само частите, които обясняват как да го настроите на вашите физически и виртуални адаптери.
Всички графични инструменти за създаване на виртуален превключвател и настройка на един виртуален адаптер за операционната система за управление бяха разгледани в тази предишна статия от поредицата. Не можете да използвате графичните инструменти за създаване на допълнителни виртуални адаптери за използване от операционната система за управление. Трябва също така да използвате PowerShell, за да създадете своя виртуален комутатор, ако искате да контролирате неговата политика за QoS. Следните команди на PowerShell се занимават с виртуалния комутатор и неговите адаптери.
Създайте външен виртуален комутатор
New-VMSwitch –InterfaceAlias AdapterName –Name vSwitch –AllowManagementOS $false –EnableIOV $false –MinimumBandwidthMode WeightИма няколко неща, които трябва да се отбележат за този конкретен cmdlet:
Параметърът „InterfaceAlias“, показан по-горе, всъщност е псевдоним за „NetAdapterName“. Псевдонимът е избран тук, защото съответства на името на параметъра и изхода на Get-NetAdapter. Командлетът е въведен с „vSwitch“ като име на виртуалния превключвател, но имате право да използвате всичко, което искате. Ако избраното от вас име има интервал в него, трябва да го затворите в единични или двойни кавички. Ако не посочите параметъра „AllowManagementOS“ или ако го зададете на true, той автоматично ще създаде виртуален адаптер за операционната система за управление със същото име като виртуалния превключвател. Пропускането на това автоматично създаване ви дава по-голям контрол върху създаването и настройването на вашите собствени виртуални адаптери. Ако не желаете да активирате SR-IOV на вашия виртуален комутатор, изобщо не е необходимо да указвате този параметър. Показано е тук като напомняне, че ако ще го зададете, трябва да го зададете, когато превключвателят бъде създаден. Не можете да промените това по-късно. Помощната документация за Get-VMSwitch показва, че по подразбиране за „MinimumBandwidthMode“ е „Weight“. Това е неправилно. Режимът по подразбиране е „Абсолютен“. Както при поддръжката на SR-IOV, не можете да промените тази настройка, след като превключвателят е създаден.Създаване на частен виртуален превключвател
New-VMSwitch Name Isolated SwitchType Private MinimumBandwidthMode WeightМного от бележките от създаването на външния комутатор се прилагат и тук. Превключвателят „EnableIOV“ изобщо не е приложим за частен или вътрешен превключвател. Превключвателят „AllowManagementOS“ е излишен: ако типът на превключвателя е „Частен“, тогава не се създава виртуален адаптер; ако типът превключвател е „Вътрешен“, тогава се създава такъв. Добавянето на един виртуален адаптер към операционната система за управление на частен комутатор ще го преобразува във вътрешен; премахването на всички виртуални адаптери на ОС за управление от вътрешен комутатор ще го направи частен.
Окончателно премахване на виртуален комутатор
Remove-VMSwitch Name vSwitchТази операция е постоянна. Целият превключвател и всичките му настройки се губят. Всички виртуални адаптери в операционната система за управление на този комутатор са загубени завинаги. Виртуалните адаптери във виртуалните машини, свързани към този комутатор, са прекъснати.
Добавете виртуален адаптер към операционната система за управление
Add-VMNetworkAdapter ManagementOS SwitchName vSwitch Name 'New vAdapter'Първото нещо, което трябва да се отбележи е, че по някаква причина тази кратка команда използва “Add” вместо нормалния глагол “New” за създаване на нов обект. Имайте предвид, че този нов адаптер ще се покаже в записите на Get-NetAdapter като vEthernet (Нов vAdapter) и това е името, което ще използвате за всички подобни кратки команди, различни от Hyper-V. Използвайте същите командлети от предишния раздел, за да конфигурирате
Извлечете списък с виртуални адаптери в операционната система за управление
Get-VMNetworkAdapter –ManagementOSПреименуване на виртуален адаптер в операционната система за управление
Rename-VMNetworkAdapter ManagementOS Name CurrentName NewName NewNameАдаптерите за операционната система за управление и виртуалните машини могат да бъдат присвоени на VLAN. Когато това се случи, виртуалният комутатор Hyper-V ще обработи процеса на маркиране на 802.1q за комуникации между виртуалните комутатори и за пакети към и от физически комутатори. Както е показано в статията за настройките на виртуалната машина, можете да използвате Hyper-V Manager, за да промените VLAN за всеки от адаптерите, свързани към виртуални машини. Можете да използвате PowerShell само за промяна на VLAN за виртуални адаптери в операционната система за управление.
Извлечете VLAN назначенията за всички виртуални адаптери на хоста
GetVMNetworkAdapterVlanМожете да използвате параметъра „ManagementOS“, за да видите само адаптери в операционната система за управление. Можете да използвате параметъра „VMName“ със звездичка, за да видите само адаптери, свързани към виртуални машини.
Задайте VLAN за виртуален адаптер в операционната система за управление
Set-VMNetworkAdapterVlan ManagementOS VMNetworkAdapterName vAdapterName Access VlanId 10Задаване на VLAN за всички адаптери на виртуална машина
Set-VMNetworkAdapterVlan -VMName svtest -Access -VlanId 7Премахване на VLAN маркиране от всички адаптери на виртуална машина
Set-VMNetworkAdapterVlan -VMName svtest –UntaggedАко една виртуална машина има повече от един виртуален адаптер и бихте искали да работите с нея отделно, това може да изисква малко повече работа. Когато GUI се използва за създаване на виртуални адаптери за виртуална машина, те винаги се наричат Мрежов адаптер, дори ако има няколко. Така че ще трябва да използвате PowerShell, за да ги преименувате, докато се създават, или няма да можете да използвате „VMNetworkAdapterName“, за да ги различите. Вместо това можете да използвате Get-VMNetworkAdapter, за да намерите други отличителни характеристики и да насочите изхода към кратки команди, които приемат VMNetworkAdapter обекти. Например искате да промените VLAN само на един адаптер, прикачен към виртуалната машина с име „svtest“. С помощта на инструментите в операционната система за гост сте установили, че MAC адресът на адаптера, който искате да промените, е „00-15-5D-19-0A-24“. С MAC адреса можете да промените VLAN само на този адаптер, като използвате следната конструкция на PowerShell:
GetVMNetworkAdapter VMName svtest | където { $_.MacAddress eq '00155D190A24' } | SetVMNetworkAdapterVlan –VMName Access VlanId 7Възможно е да използвате PowerShell за конфигуриране на мрежа за вашия Failover Cluster, но е много неелегантно с текущото състояние на тези кратки команди. Понастоящем те не са добре конфигурирани, така че трябва директно да манипулирате стойностите на свойствата на обекта и настройките на регистъра по начини, които са рискови и податливи на грешки. Много за предпочитане е да използвате Failover Cluster Manager, за да направите тези настройки, както е обяснено в тази статия по-рано в поредицата.
Във виртуалната мрежа Hyper-V има много за смилане. Това, което видяхте досега, наистина е само основите. За сравнително опростено внедряване с не повече от няколко дузини виртуални машини може никога да не се нуждаете от повече информация. Тъй като плътността започва да се покачва, необходимостта от по-тясно настройване на мрежата нараства. С гигабитови адаптери най-добрият ви вариант е мащабиране. 10GbE адаптерите ви позволяват да преодолеете ограниченията на физическия процесор с редица техники за разтоварване, главна сред които е VMQ. Започнете проучването си по тази тема, като започнете с окончателната поредица от статии по темата, VMQ Deep Dive.
В противен случай най-добрите ви следващи стъпки са да практикувате с кратките команди на PowerShell. Например, научете как да използвате Set-VMNetworkAdapter за модифициране на виртуални адаптери по начин, подобен на процедурите, които видяхте в по-ранните статии за GUI. С малко усилия ще можете да промените групи от адаптери наведнъж. Мрежата на Hyper-V може да е многостранна и сложна, но нивото на контрол, предоставено ви, е еднакво огромно.
PREV: 5 предимства и недостатъци на виртуализацията | Недостатъци...
![[Решен] Не може да се свърже с MySql сървър на localhost (10061) (Вижте темата) * Форум на общността на Apache OpenOffice](http://website-google-hk.oss-cn-hongkong.aliyuncs.com/drawing/26/2022-3-1/7051.jpeg "[Решен] Не може да се свърже с MySql сървър на localhost (10061) (Вижте темата) * Форум на общността на Apache OpenOffice")
