Innledning
Som jeg nevnte i min forrige artikkel i denne serien, er planlegging nøkkelen til suksess i alle tilfeller. Dette er ikke mindre sant når det kommer til noe som Windows NIC Teaming, så denne artikkel undersøker ulike ting du må være oppmerksom på og vurdere før du prøver å implementere NIC Teaming på Windows Server 2012 eller senere.
Å velge riktig teaming modus
Vi så av figur 1 i forrige artikkel at når du bruker brukergrensesnittet for å opprette et nytt team du har et valg mellom tre teaming moduser å velge mellom:
Statisk Teaming
Slå Independent
LACP
Dette er faktisk litt forvirrende fordi det er egentlig bare to typer teaming modi:
Slå uavhengig
Slå avhengig
UI ikke viser en modus som heter Switch Dependent men i stedet viser to typer bryter avhengige moduser:
Statisk Teaming
LACP
Så dine valg for teaming modus virkelig se slik ut:
Slå Independent
Slå Dependent
Statisk Teaming
LACP
La oss undersøke dette nærmere.
Når du bruker Switch Uavhengig teaming
Slå uavhengig er standard teaming modus når du oppretter et nytt team. Denne modusen forutsetter at du ikke trenger dine Ethernet-svitsjer til å delta i å gjøre NIC teaming skje for serveren din. Med andre ord, forutsetter denne modusen Ethernet-svitsjen er ikke engang klar over at de nettverkskort koblet til den blir slått.
På grunn av dette, velge Switch Uavhengig modusen lar deg koble hver NIC i et team til et annet Ethernet-svitsj på ryggraden din. Men du kan også bruke denne modusen når alle nettverkskort i klubben er koblet til det samme Ethernet-svitsj.
Et scenario der du kan bruke denne funksjonaliteten er å gi feiltoleranse når det gjelder en av de teamed nettverkskort sviktende. For eksempel kan du lage et lag fra to nettverkskort (NIC1 og Nic2) på serveren din, og deretter koble NIC1 til switch1 og Nic2 å switch2. Deretter kan du konfigurere NIC1 som aktiv adapter for laget, og Nic2 som standby adapter for laget. Så hvis NIC1 mislykkes, vil Nic2 automatisk bli aktive og serveren vil ikke miste sin tilkobling med ryggrad.
Vær oppmerksom på at ovennevnte tilnærming, som er blant annet kalt Aktiv /Passiv Teaming eller Aktiv /Standby teaming, gir feiltoleranse, men ikke båndbredde aggregering for serverens tilkobling til nettverket. Du kan like gjerne la begge nettverkskort konfigurert som aktiv og få både feiltoleranse og båndbredde aggregering hvis du foretrekker det, men valget er opp til deg.
Når du bruker Switch Dependent teaming
kan bare bruke en av Switch avhengige moduser (statisk teaming eller LACP) hvis alle teamed nettverkskort er koblet til det samme Ethernet-svitsj på ryggraden din. La oss vurdere
Statisk Teaming (også kalt generisk teaming eller IEEE 802.3ad teaming) krever konfigurering både serveren og Ethernet-svitsj for å få laget til å fungere. Vanligvis bare enterprise-klassen Ethernet-svitsjer støtte denne typen funksjonalitet, og siden du må konfigurere det manuelt på Ethernet-svitsj det krever ekstra arbeid for å få det til å fungere. Plus manuelt konfigurere noe øker alltid oddsen for konfigurasjonsfeil skjer hvis du gjør noen form for feil under opprettelsen prosessen. Hvis mulig, prøv å holde seg borte fra å følge denne tilnærmingen til NIC teaming på Windows Server.
LACP (også kalt IEEE 802.1ax teaming eller dynamisk teaming, som ikke må forveksles med den nye Dynamic lastbalansering modus tilgjengelig for NIC Teaming i Windows Server 2012 R2) bruker Link Aggregation Control Protocol å dynamisk identifisere nettverksforbindelser mellom serveren og Ethernet-svitsj. Dette gjør LACP overlegen statisk teaming fordi det gjør det mulig for serveren for å kommunisere med Ethernet-svitsj i teamet prosessen, og dermed muliggjør automatisk konfigurering av laget både på server og Ethernet-svitsj. Men mens de fleste bedriftsklassen Ethernet-svitsjer støtte LACP, du vanligvis må aktivere det på utvalgte bytte porter før den kan brukes. Så LACP er mindre arbeid å konfigurere enn statisk Teaming, men fortsatt mer arbeid å sette opp enn slå uavhengig teaming som er standardalternativet for Windows NIC Teaming.
Velg Slå Independent teaming
Bunnen linjen er da at Switch Uavhengig teaming er vanligvis det beste valget for å velge for teaming modus når du oppretter en ny NIC Team for to grunner. Først, ikke må du utføre noen konfigurasjon på Ethernet-svitsj for å få det til å fungere. Og andre, kan du få to typer feiltoleranse:
Beskyttelse mot svikt i en NIC i klubben
Beskyttelse mot svikt i en Ethernet-svitsj koblet til en teamed NIC (når du kobler ulike teamed nettverkskort til ulike Ethernet-svitsjer)
Men det er et par av scenarier beskrevet senere under der Switch Dependent teaming kan være det beste valget hvis din Ethernet Switch støtte slik funksjonalitet og du er klar for å konfigurere den.
Velge riktig lastbalansering modus
La oss si at du har valgt Switch Uavhengig teaming som teaming modus for en ny NIC lag du oppretter. Din neste beslutning er som lastbalansering modus du skal bruke. Som beskrevet i forrige artikkel i denne serien, NIC Teaming i Windows Server 2012 støtter to forskjellige lastbalansering moduser: Adresse Hash eller Hyper-V Port. Windows Server 2012 R2 legger et tredje alternativ for lastbalansering modus kalt Dynamic, men på tidspunktet for å skrive denne artikkelen er det få detaljer om hvordan det fungerer så vi får se det senere når mer informasjon blir tilgjengelig. Og hvis du serveren kjører Windows Server 2012, er dette lastbalansering modusen ikke et alternativ for deg anyways.
Når du bruker Adresse Hash
Den største begrensningen av denne lastbalansering tilnærmingen er at innkommende trafikk bare kan mottas av et enkelt medlem av teamet. Grunnen til dette har å gjøre med den underliggende driften av hvordan adressen hashing bruker IP-adresser og TCP-portene til frø hash funksjon. Så et scenario der dette kan være det beste alternativet ville være hvis serveren kjørte den type arbeidsmengden der inngående trafikk er lys, mens utgående trafikken er stor.
Høres det kjent ut? Det er akkurat det en webserver som IIS opplevelser i form av nettverkstrafikk. Innkommende HTTP /HTTPS forespørsler er generelt korte strømmer av TCP trafikk. Hva blir pumpet ut i respons på slike forespørsler, men kan inneholde tekst, bilder og video.
Når du bruker Hyper-V Port
Denne lastbalansering tilnærming affinitizes hver Hyper-V-port (dvs. hver virtuelle maskin) på en Hyper-V host til en enkelt NIC i klubben til enhver tid. I utgangspunktet hva du får her er ingen lastbalansering fra den virtuelle maskinen perspektiv. Hver virtuell maskin kan bare bruke én teamed NIC om gangen, så maksimal inngående og utgående gjennomstrømming for den virtuelle maskinen er begrenset til det som er levert av en enkelt fysisk NIC på verten.
Når kan du bruke denne formen for lastbalansering? Et typisk scenario kan være hvis antall virtuelle maskiner som kjører på verts er mye større enn antallet fysiske nettverkskort i teamet på verten. Bare sørg for at de fysiske nettverkskort kan gi tilstrekkelig båndbredde til de jobber i det virtuelle maskiner.
Andre alternativer
Hvis du implementerer NIC teaming på en Hyper-V host og virtuelle maskiner trenger å være i stand til å utnytte båndbredden fra mer enn én NIC i laget, deretter et alternativ for deg (hvis Ethernet-svitsj støtter det) er å konfigurere LACP eller Statisk Teaming som teaming modus og adresse Hash som lastbalansering modus. Dette er mulig fordi det er hvordan du konfigurerer Ethernet-svitsj som bestemmer hvordan trafikken vil bli fordelt over lagets medlemmer. Dette scenariet er litt uvanlig men fordi vanligvis hvis du har en virtualisert arbeidsmengde som krever høy båndbredde for både innkommende og utgående trafikk (for eksempel en stor SQL Server-database arbeidsmengde) da er du sannsynligvis bare kommer til å ha en eller to virtuelle maskiner som kjører på Hyper-V host.
Så er det spørsmålet om gjennomføring NIC teaming innenfor gjesteoperativsystemet av den virtuelle maskinen i motsetning til den underliggende verts operativsystem. Men vi skal la diskusjonen om dette emnet før neste artikkel i denne serien, og etter det vil vi begynne å undersøke hvordan Windows Powershell kan brukes til å konfigurere og administrere NIC teaming på Windows Server 2012 eller senere. Anmeldelser