Teknikbloggen – Sida 3

Molntjänster – skillnad på moln och moln

Det snackas mycket om molnet och cloud hosting.

Vad är molnet?

Med molntjänster (även kallat cloud Computing) menar man möjligheten att köra serverbaserade applikationer eller program över Internet. Traditionellt så brukar man hantera applikationer inom ett företag eller en organisation genom att installera applikationen på en egen fysisk server. Dessutom så ansvarar man för drift och underhåll av både server samt applikation själva eller genom att överlåta på en extern IT-leverantör (outsourcing).

Inom molnet är det istället ofta tjänsteleverantörer som svarar för installation på sin server samt ansvarar för drift och underhåll av miljlön i egna datacenter. För att göra allt det här möjligt så brukar tjänsteleverantören använda virtualiserings-teknologi för att kunna dela upp resurserna bland olika applikationer och ”virtuella privata servrar”. På så vis kan man maximera resursutnyttjandet av de fysiska servrarna genom att tilldela precis så mycket resurser som behövs – till skillnad från det resursslöseri man riskerar att ha i en traditionell miljö.

Skillnad på moln och moln

Jag anser att olika leverantörer av molntjänster kan delas in i tre olika kategorier eller nivåer, så kallade tiers. Dessa nivåer är vad som spelar in på kvalité och pris av tjänsten. Ju högre nivå av tjänsten desto dyrare.

Den främsta skillnaden bland olika tiers är IOPs (operationer per sekund) kapacitet på deras lagringsplatform. Därefter kommer funktionaliteten.

IO-prestandan är så pass viktig att om du har otur att välja en leverantör som har låg prestanda eller har sparat in på lagringsmiljön kan din virtuella privata server påverkas negativt av långsam läs- och skrivkapacitet. Priset på lagringsutrymme spelar roll på prestanda!

Har man inte högt ställda krav på IOPS prestanda och hellre vill ha maximalt lagringsutrymme så kanske man inte behöver välja de dyrare tiers. Har man dock krav på prestanda så får man nog satsa på de högre tiers.

Nedan har jag försökt klassifiera olika tiers och deras egenskaper:

– Premium tier
Högst driftsäkerhet, dedicerade infrastrukturresurser med flera niors upptid SLA. Deras lagringsmiljö är oftast bland de mest kvalificerade och högpresterande som kostat miljoner att driftsätta.
Oftast egen tekniskt platform som de själva driftar och utvecklar. De lever på sitt namn och har råd att ta betalt.
Dessa leverantörer brukar även leverera sin mjukvara till företag så att de kan hosta privata moln (virtuella miljöer). Ett exempel på dessa leverantörer är VMWare.

– Enterprise tier
Steget under Premium tier. De håller hög nivå på sin infrastruktur men är inte lika stora som premium tier. De har mindre datahallar och licensierar sin mjukvara från Premium tier leverantörer. De satsar även på att kunna leverera vad de lovar vilket driver upp priser någorlunda för lagringsutrymmen (SAN i hundratusenkronors klassen) men är inte lika dyra som Premium.

– Budget tier
Billigaste billiga. Vissa begränsningar i virtualiseringsfunktioner och överbokar gärna sina resurser för att hålla låga priser till slutkunder. De kör ofta mjukvarubaserade filsystem för att kunna maximera tillgängligt lagringsutrymme på bekostnad av IOPs prestanda. Distribuerade filsystem körs på vanliga konsument SATA diskar som har maximal lagringskapacitet, låg IOPs men även låga priser.

Hur kan man skilja på ett moln från ett annat då?
Priset!
Titta på grundpaketet från leverantören.
Kostar VPS:en man vill beställa bara mellan 50 och 120kr/må så kan man vara säker på att de sparat in på något. Är lagringsutrymme extremt billigt så kan man vara bombsäker på att det är distribuerade filsystem som använder långsamma SATA diskar för maximalt utrymme.
En start kostnad runt 170kr/mån brukar indikera Enterprise tier och allt ovanför 250kr/mån är Premium. Priserna för lagringsutrymme springer gärna iväg till många tior per GB diskutrymme.

Kraften av Unix?

Jag läste en intressant artikel på IDG där man tar upp hur man kan använda MacPorts som pakethanterare under Macintosh.
Mycket bra genomgång även om jag får passa på att ge Mac OSX en känga eftersom man kunnat göra detta under Linux sen någon gång på 90-talet 🙂

Mina personliga favoriter under olika distributionsträd är följande:
I Debian, Ubuntu och andra distributioner baserat på Debian har vi apt-get / aptitude.
I Gentoo har vi emerge / portage.
I RedHat och Redhat kompatibla distributioner så som CentOS och WhiteHat har vi yum.

Absolut snabbast av alla dessa är apt för Debian även om emerge / portage på Gentoo kan tänkas vara den mest flexibla av paketeringssystemen.

Hur skiljer sig då pakethantering under Linux mot t.ex. Windows?
Jo, man på Linux har man ofta stora arkiv online med tillgänglig mjukvara som man kan vraka och välja bland. Det går att genom ett kort kommando både söka, installera och avinstallera alla mjukvaror som behövs. Alla filer som behövs laddas ned vid behov och installeras snabbt och enkelt. Ibland skulle jag vilja säga att detta gör Linux enklare än Windows för en administratör!

Använder du Android eller iPhones market funktioner för att tanka appar kan du tänka dig att det funkar liknande.
Du söker en app och väljer den helt enkelt för installation.

I Windows får du oftast leta upp den mjukvara du vill ha, fixa en installationsfil eller cd-skiva och därefter installera.
Hoppas verkligen att Microsoft följer efter och ger upp tänket med att behöva ladda ned en ISO för att bränna ned på skiva varje gång man vill installera någon större applikation. Vi på Adminor är SPLA partner men det tar avsevärt mycket längre tid att installera programvaror från Microsofts licenspartnerprograms webbsidor än motsvarande från andra operativsystems leverantörer. Synd!

Varnish cache – en case-studie

En kväll blev Adminor uppringd av en webbportal som hade ett akut problem.

Problemet
Deras sida hade legat nere under halva dagen och mesta delen av kvällen. När sidan väl var uppe tog det över 10 sekunder för sidan att ladda.
Mesta dels var problemet självförvållat genom ökande popularitet av deras webbsida.

De var i akut behov av att lösa problemen men hade inte möjlighet att byta server snabbt på grund av budgetbegränsningar och intern miljö.
På mjukvarusidan fanns en vanlig WordPress installation på en Apache webbserver och MySQL-databas. Utöver det hade dom själva redan försökt lösa problemet genom att köra wordpress cache plugin.

En till synes omöjlig uppgift när budget begränsar och det inte fanns mycket man kan göra på mjukvarusidan.

Förberedelser

Det första vi tittade på var serverinställningarna på Apache och MySQL. Vi kunde dock inte se några underligheter utan inställningarna var rätt hyffsade. Det var helt enkelt så att de måste frigöra resurser på något vis, antingen genom att köpa in ny hårdvara eller förbättra applikationen.
Vi kom då med ett tredje förslaget att istället implementera Varnish som en caching proxy framför deras webbportal. På så vis skulle man kunna cacha de dynamiska förfrågningarna.

Felåtgärd

Ofta måste man göra en fullständig undersökning av kundens miljö eftersom man inte vill orsaka problem med att ändra inställningar för server.
I detta fall var det ganska enkelt när servern bara har en site som körs och sidan ändå var nere mera än den var uppe pga det höga trycket.

Vi körde därför igång på direkten. Det första vi gjorde var att göra en snabbanalys. Detta gjorde vi genom att installera grafverktyg och statistikinsamling på det systemet som var berört.

Adminor identifierade det material som MÅSTE vara dynamiskt och vilket material som kunde cachas. Det visar sig att allt förstasidematerial och dess undersidor med enkelhet kunde cachas i åtminstone 10 minuter. Restererande material som publikationsdel och administrationssidor fick inte cachas.
Sen diskuterade vi med kunden om detta verkade överenstämma. Att installera Varnish är rätt enkelt så 2h efter att kunden först tog kontakt så var en lösning färdigimplementerad.

Resultat

Graferna nedan visar de första 20 minutrarna då vi precis installerat övervakningen och sen den kraftiga resursminskning efteråt när Varnish aktiverats.

Datapunkterna på CPU-grafen visar iowait, user och system CPU-utnyttjande som låg långt över det rekommenderade. Minnesanvändningen låg över det som fanns fysiskt installerat så att server var tvungen att swappa (läsa / skriva från långsammare diskminne).
Efter Varnish-installationen så har CPU användningen minskat från >100% till endast en 1/4 del utav de tillgängliga resurserna som högsta nivå under dagarna. Minnesgrafer är nu jämn under dagarna med avtagande ökning (normalt och hälsosamt) istället för den kaotiska höga commit nivån (5.96GB!) som låg ovanför den fysiska gränsen i början av datapunkterna.

Det ska nämnas att innan Varnish implemeterades kunde portalen endast ta emot ett tjugotal samtidiga besökare. Efter förändringen så gjorde vi ett lasttest som visade att det nu var serverns bandbreddsanslutning som kommer begränsa – men det är långt tills dess. Detta ger nu portalen en hel del utrymme att växa i utan att öka sina serverkostnader!
Efter Varnish togs i bruk laddades 100% av besökarna under 0.5sekunder enligt apache benchmark statistik.

Kommando: ab -n 1000 -c 5 http://www.domain.se/

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.domain.se (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software:        Apache/2.2.9
Server Hostname:        www.domain.se
Server Port:            80

Document Path:          /
Document Length:        71552 bytes

Concurrency Level:      5
Time taken for tests:   57.714 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      72030893 bytes
HTML transferred:       71552000 bytes
Requests per second:    17.33 [#/sec] (mean)
Time per request:       288.570 [ms] (mean)
Time per request:       57.714 [ms] (mean, across all concurrent requests)
Transfer rate:          1218.82 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       39   40   0.6     40      51
Processing:   202  248  77.6    204     447
Waiting:       40   41   2.7     41     112
Total:        241  288  77.6    244     487

Percentage of the requests served within a certain time (ms)
  50%    244
  66%    245
  75%    256
  80%    407
  90%    444
  95%    446
  98%    447
  99%    448
 100%    487 (longest request)

I nästa blogg-inlägg kommer jag gå igenom vilka Varnish konfigurations & VCL-regler vi fick definera – vad man måste göra för att få en cache att fungera och vilka undantag som måste göras för respektive del för att dynamiskt material ska fungera korrekt.

Kompetens – HTTP, server- och webboptimering

Adminor erbjuder redan idag expertis inom cache- och reverseproxy lösningar så som nginx, Varnish och Squid. Därför är det inte mer än rätt att vi snart kommer publicera våra första blogg-artiklar om olika cache- och reverseproxies.

Först ut kommer vi vara med att gå igenom varnish, dess funktion, hur vcl:erna fungerar och hur exempel på vart det används. Vi kommer steg för steg gå igenom hur man kan förbättra prestanda på webbsidor och på så vis minska belastningen på servrar, förbättra upplevelsen för besökare samt göra bakomliggande infrastrukturer mer kostnadseffektiva.

Senare kommer vi även beröra hur nginx och mindre kända lösningar som POUND – REVERSE-PROXY AND LOAD-BALANCER kan användas för att utöka funktionaliteten av de olika programmen.
T.ex. kommer vi gå igenom hur man får Varnish att fungera bakom SSL-siter (https) genom att använda antingen nginx eller Pound , för och nackdelar med endera lösning.

I en senare bloggartikel kommer vi även belysa på vilket sätt proxylösningar kan förbättra säkerheten för webbsidan och dess besökare.

Kort om Linux- och MySQL-användarhantering.

Jag fick en fråga på en kund om skillnaden mellan linux-användare (system users) och de användare som finns i MySQL.
Vissa gånger kan det vara lätt att blanda ihop om man sköter sitt eget linux system.
T.ex. en vanlig webbserver med databas där man har MySQL som databasmotor.

Det lättaste att komma ihåg är att MySQL och systemanvändarna är helt skiljda. Det är helt enkelt olika användartabeller.

Lite förenklat så är alla systemanvändare i linux (som nås via t.ex. ssh) är definerade i olika filer (med hjälp av olika verktyg för lösenordsändring, typ passwd):

/etc/passwd – användarnamn, userid, gruppid (primär grupp som användare tillhör), hemkatalog, shell som ska köras vid inloggning typ /bin/bash

/etc/shadow – krypterade lösenorden som tillhör användare

/etc/group – gruppdefinationer, gruppid och medlemmar av sekundära grupper
Mer matnyttig information finns längst ned i denna post.

Det finns undantag, t.ex. om man använder LDAP eller andra centrala användardatabaser – men i detta inlägg förenklar jag och tar inte upp central användarhantering.

MySQL är ett program likt alla andra på ett system men körs ofta som en ”daemon” under linux och exekvieras av en vanlig systemanvändare, ofta som administratörs-användare ”root”.
När MySQL körs så tillhandahållet MySQL en egen miljö för att hantera databaser. Det finns logik , datalagring och användarhantering med mera.
I MySQL lagras användarna i en speciell reserverad tabell ”user” under databas med namnet ”mysql”. Det är mest ett sammanträffande att man använder samma namnkonvention som unix-system där superusern kallas ”root”.

mysql> show tables;
+—————————+
| Tables_in_mysql           |
+—————————+
| columns_priv              |
| db                        |
| func                      |
| help_category             |
| help_keyword              |
| help_relation             |
| help_topic                |
| host                      |
| proc                      |
| procs_priv                |
| tables_priv               |
| time_zone                 |
| time_zone_leap_second     |
| time_zone_name            |
| time_zone_transition      |
| time_zone_transition_type |
| user |
+—————————+
17 rows in set (0.01 sec)
17 rows in set (0.01 sec)

I MySQL är användare lagrade på formen permissions och privileges. Permissions sätts upp med access per databas och även på tabellnivå för läs/skriv samt vilken ”host” som användare får ansluta från % (wildcard, alla hosts) eller per IP/subnät. En bra introduktionsguide till hur man hanterar och administrerar användare i MySQL finns länkade i slutet av denna post.

En likhet mellan systemanvändare och MySQL användare är säkerhetsaspekten. Man bör t.ex. aldrig tillåta ”root” på ett system eller ha en superuser på Mysql som kan logga in från vilket IP/domän som helst.
Man ska alltid försöka begränsa access och ge ut de privilegier som beövs till de databaser som behöver nås – per IP.
Rekommenderar att läsa följande dokumentation för användaradministration i Linux (även andra unix system är liknande): http://www.comptechdoc.org/os/linux/usersguide/linux_ugusers.html
Mer ingående information om MySQL permissions kan finnas här: http://www.databasejournal.com/features/mysql/article.php/3311731/An-introduction-to-MySQL-permissions.htm

Layer2 stabilitet (BPDU guard)

Att skydda kunder från andra kunder är en fråga som varit på tapeten många gånger.
Enkla åtgärder som att partitionera nätet med egna VLAN och subnät är bara några av de saker vi gör för att förbättra prestanda i nätet genom att minska ”skräp”-trafik. Ibland behövs ytterligare lite nätverks-magi.

I denna post kommer jag beskriva en av de metoder vi använder för att skydda våra nätverk på länklagret (layer 2).

Här om dagen fick jag en historia berättad för mig där en kille had stoppat in en kabel i fel nätverksport på sin skola.
Tydligen hade det sänkt hela kommunens nätverk när en switch-loop uppstått.

Här har vi ett solklart exempel på när nätverks-ansvarig inte gjort sin läxa.
Vad som hände här var att switchar får multipla vägar som trafiken kan gå. Ethernet är inte alltid så smart så att det kan förstå när nån gör fel. Den försöker bara matcha vad som händer på det fysiska lagret.

Ett värre exempel var nyligen då ett sjukhus datornätverk gick ned helt och hållet.
Detta berodde på att någon sjuksköterska hade kopplat in en nätverkskabel i fel nätverksuttag. Felet upptäcktes inte förrens man gått igenom varje avdelning där det fanns nätverk.

Vad som skapar detta fel om man inte vidtagit åtgärder mot detta är att när en port aktiveras och en ny väg till samma switchar märks så uppstår en loop. Paketen skickas runt runt, arp requests skickas fel och eventuell broadcast storm .

En lösning är att sätta upp korrekta spanning tree protocol (STP) konfigurationer. Beroende på switch-tillverkare och modell så aktiverar man STP per VLAN och port. Anger vilken port som kommer vara primär, och vilken som kommer vara sekundär vid eventuellt bortfall för att få redundans.

För cisco så finns det en superb beskrivning på Ciscos portal här .
Själv föredrar jag att lösa redundans i core och distribution på andra vis – men problemet med loopar kan fortfarande uppstå. Detta löser jag på ett smidigare sätt än STP.
Svaret på detta problem (och som kommunens it-tekniker borde kunnat) är BPDU guard.
Det är så enkelt och går snabbt att implemetera på ciscoutrustning och annan utrustning som stödjer det.

I cisco-miljö görs det på följande vis:

CatOS Command

Console> (enable) set spantree portfast bpdu-guard enable 

Spantree portfast bpdu-guard enabled on this switch. 

Console> (enable)

Cisco IOS Software Command

CatSwitch-IOS(config)# spanning-tree portfast bpduguard 
CatSwitch-IOS(config)

Vad detta gör är att när en switch loop upptäcks försätts ena anslutningen i inaktiverat (disable) läge.
Om man vill att switchen ska försöka återansluta efter ett tag kan man konfigurera automatiskt retry. Annars kommer den felande länken vara inaktiverad tills man löser det manuellt.

CatOS Commands

Console> (enable) set errdisable-timeout interval 400 

Console> (enable) set errdisable-timeout enable bpdu-guard

Cisco IOS Software Commands

CatSwitch-IOS(config)# errdisable recovery cause bpduguard

CatSwitch-IOS(config)# errdisable recovery interval 400

Note: The default timeout interval is 300 seconds and, by default, the timeout feature is disabled.

BPDU Guard bör man konfigurera på alla kritiska switchar där loopar kan uppstå. Det räcker med något så enkelt som att koppla en kabel från en port till en annan på samma switch ibland för att skapa en loop.
Källa: http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a008009482f.shtml

Uppdatering av VMWare ESXi 4.0 till 4.1

För de av oss som använder VMWare ESXi så kommer uppdateringar med jämna mellanrum. Ibland små buggfixar men ibland större revisioner som ger bättre prestanda och mer funktioner.

Nu har en sådan uppdatering kommit i sommar. Vi brukar avvakta med större uppgraderingar tills dess att alla barnsjukdomar är åtgärdade.

Inatt utförde Adminor uppgradering av våra interna VMWare ESXi miljöer från av VMWare ESXi 4.0 till 4.1 .

Innan 4.1 kunde man använda VMWare host update utility för att göra uppdateringar , denna har nu fasats ur för att förbereda avveckling av produkten ”ESX” till förmån för ”ESXi”.
Nu får man istället använda host update manager i vCenter om man har den ”licensen” , ”esxupdate” eller min favorit ”vihostupdate” .

Förutsätter att du redan har ett konto på vmware.com och en separat ESXi server du kan köra vMA (vmware Management Assistant) appliance. Har du inte det kan du ladda ned konsol-verktygen till valfritt operativsystem här.

För att följa vår guide helt och hållet behöver du även en webbserver du kan ladda upp uppgraderingsfilen (.zip) som används med vihostupdate.

Lättast är att använda vihostupdate från vMA och kan göras med ett par enkla steg.
Förberedelse:
– En webbserver dit du kan lägga filer.
T.ex. apache eller IIS.

– vMA appliance
Kör appliance .ovf filen för vMA (från länken ovan) och kör igång på din ESXi server, alternativt klientmjukvarupaketet för ditt operativsystem.

– Uppgraderingsfilen (.zip)
Gå till www.vmware.com , logga in till ditt konto och gå till ESXi portalen (beroende på din license-nivå). För fria ESXi gå till ”Evaluation and Free products – VMWare ESXi”.
Ladda ned rätt upgrade zip , t.ex. ”ESXi 4.1 (upgrade ZIP from ESXi 4.0)” för VMWare ESXi 4.0 . Välj en annan för andra versioner.
Lägg denna .zip fil på din webbserver som kan nås via http.

Enkla uppgraderingssteg:

1. Migrera bort eller stäng ned dina virtuella maskiner på den ESXi host som ska uppgraderas.

2. Sätt din ESXi host i ”maintenance mode”.

3. Har du SSH access till ditt ESX/ESXi system kan du använda metod B annars använd metod A.

Metod A: Gå in i vMA appliance konsolen eller en kommandopromt om du laddat ned vmware console verktygen.

Skriv ”vihostupdate –server ”ip eller hostname till din esxi server” -i -b http://adresstilldinwebbserver/uppgraderingsfilensnamn.zip -B ESXi410-GA”

Kör du ESX istället för ESXi använder du ”ESXi410-GA-esxupdate” istället för bara ESXi410-GA ovan.

Metod B:
SSH:a till din ESXi/ESXi box och skriv i konsolen:
”esxupdate –bundle http://adresstilldinwebbserver/uppgraderingsfilensnamn.zip update”

Funkar allt ska din output vara:
”Enter username: din användare
Password:
The update completed successfully, but the system need to be rebooted for the changes to be effective.”

4. Starta om ditt ESX/ESXi och gå ur mainteinance mode.
OBS! Om du kör vCenter ska den uppdateras före vSPhere client. vSphere client måste uppgraderas oavsett.

Klart!

Källa:

kb.vmware.com/kb/1022140 – VMware KB: Upgrading ESX 4.0 to ESX 4.1

iSCSI och multipathIO

I detta blogginlägg kommer jag använda en hel del begrepp.
”Storage area network” förkortat till ”SAN”. ”Hosts” är de servrar eller maskiner även kallade ”iSCSI initiator” som ansluter mot de virtuella diskar som görs tillgänglig för hosts över nätverket. Dessa virtuella diskar över iSCSI kan även benämnas ”iSCSI target”.

Jag fick nyligen möjlighet att börja göra drifttester med Dells nya SAN i samband med att Adminor inhandlade nytt för vår driftmiljö.

MD32x0(i) är den nya generationen som ersätter den äldre Powervault MD3000i. Den nya modellen finns liksom föregångaren med med ”i” version (iSCSI) och SAS storage array ”utan i”. Modellen MD32x0 kan direktanslutas mot 8st serverhosts (upp till 8st direktanslutna, eller 4st i redundant) medan iSCSI varianten drar nytta av gigabit ethernet för upp till 32 hosts.

Det finns alltså följande varianter av ”MD32x0″/”MD32X0i”
iSCSI variant:
MD3220i – plats för 24st 2.5″ diskar
MD3200i – plats för 12st 3.5″ diskar

SAS storage array variant för direktanslutning:
MD322o- samma antal diskar som motsvarande ”i” variant
MD3200 – samma antal diskar som motsvarande ”i” variant

MD32x0(i) kan köras i simplex eller duplex läge. Det som skiljer är att i simplex läge har man bara en controller utan redundans. Med duplex körs controller i mirror-läge med en annan controller. Även prestanda kan förbättras genom duplex läge. En till controller kan alltid köpas till senare, jag vet dock inte ännu ifall man kan blanda SAS storage array RAID controller med SAN iscsi RAID controller.

—–

Att sätta upp ett SAN kräver en hel del planering. Vi hade givetvis en drös egna frågor inför driftsättningen.

Illustration ovan – enkelt utkast över planen för driftsättning.

Hur bör man då koppla upp ett SAN för att erbjuda både redundans och prestanda?
Jo, man väljer så klart multipath I/O.
Följer man best practise papers så bör ett SAN va uppkopplat på dedicerad iSCSI VLAN och dedicerad switchar för iSCSI trafik med flera ”paths” (vägar). Det var precis den lösningen vi själva valde.
Redundanta gigabit switchar, dedicerade iSCSI VLAN och iSCSI paths fördelade jämnt över de två switcharna.

För att få bästa prestanda bör den host som ansluts mot SAN ha minst 2 nätverkskort uppkopplad mot respektive dedicerad switch på iSCSI VLAN. (se bilden ovan) På så vis kan datatrafik fördelas över olika paths och lastbalanseras beroende på multipath policy. I VMWare används ”most recently used” (MRU), ”round robin” (RR) eller ”fixed”.

Har man gjort rätt med adresseringar, subnät och multipath policy så har man ett riktigt kraftpaket i ett iSCSI SAN.

Den slutgiltiga konfigurationen för driftmiljö virtualiseringscluster är:
1x MD3220i (2 controllers i duplex-läge för redundans)
2x redundanta gigabit switchar med multipla vägar för multipath I/O.
4x subnät (ett per iscsi host port grupp) och motsvarande IP-inställningar på hosts
1x Dell M1000 bladchassi med expansionsmöjlighet med fler bladservrar.

Det enda kluriga med MD3220i har egentligen varit managerings-GUI:t som förvisso är mycket bra men har några barnsjukdomar. Vi fick rapportera några några ”kosmetiska” GUI buggar till Dell 🙂

Ytterligare resurser och källhänvisning:
Att sätta upp multipath I/O och iSCSI med vsphere:
A multivendor post on using iscsi with vmware vsphere