Permalänk
Medlem

SSD SAN/NAS/DAS

Hej hopp!

Sorry för wall of text nedan, försöker vara så beskrivande som möjligt.

Har i undervisningssyfte ett gäng (8st.) begagnade HP-servrar (DL380G5 ,2xE5440, 20-24GB RAM) som kör ESXi med 2-3 virtuella servrar per maskin. De virtuella servrarna lagras på konsument-SSD:er (240GB Corsair och Toshiba blandat) och här kommer problemet in, SSD:ernas utrymme används inte särskilt smart, det tenderar att bli utrymme som inte kan användas på dem.
Därför har jag börjat funderat på hur jag ska gå till väga i nästa steg.

Vi har fått ett erbjudande om att köpa en begagnad disklåda från DELL (Compellent EB-2425) där vi verkligen kan växa genom att dels stoppa in befintliga SSD:er, dels genom att fylla på med fler vid behov.
Enligt leverantören behövs till disklådan en controller med externa portar (vi har fått som förslag HP H221) för att ansluta till en helt annan server vi har tillgång till (HP ML330) och därefter kan vi dra nytta av disklådan och köra JBOD genom den till en ZFS-maskin (inte helt bestämt OS o.s.v.).

Nu behöver jag hjälp här, ska vi satsa på leverantörens förslag och därmed riskera att konsument-SSD:erna inte fungerar (tråkigt när tillverkare försöker hindra användare att nyttja icke-tillverkarspecifik utrustning) eller finns det någon som har ett annat förslag? Vi behöver gissningsvis fysisk plats för minst 12 2.5" SSD:er för att kunna rymma fler virtuella servrar i framtiden (alla servrar är f.ö. inte igång samtidigt, därför klarar vi oss internminnesmässigt och CPU-mässigt men inte diskmässigt eftersom utrymmet allokeras oavsett om servrarna är igång eller ej.

Tacksam för inputs från alla håll!

Glömde få med en viktig punkt som jag dock nämner i sista stycket, tanken är alltså att öka antalet virtuella servrar per fysisk server till 5-6 st.
Permalänk
Medlem

Beror väl lite på hur mycket utrymme du behöver. Men eftersom de rör sig om en del VMs 16-24st som ska ha lagring över nätverket (iSCSI) så behöver du nog ha dedikerade switchar till det. Men du körde inte alla samtidigt?

Men annars kanske du kan ta en av dina 8st servrar och bygga om till lagring och på så vis spara in lite pengar? Blir ju iSCSI ändå...

EDIT: Såg din edit nu efter jag hade postat. Det beror ju lite på hur många VMs som kommer att vara igång samtidigt.

Permalänk
Medlem
Skrivet av HerrNilsson:

Beror väl lite på hur mycket utrymme du behöver. Men eftersom de rör sig om en del VMs 16-24st som ska ha lagring över nätverket (iSCSI) så behöver du nog ha dedikerade switchar till det. Men du körde inte alla samtidigt?

Men annars kanske du kan ta en av dina 8st servrar och bygga om till lagring och på så vis spara in lite pengar? Blir ju iSCSI ändå...

EDIT: Såg din edit nu efter jag hade postat. Det beror ju lite på hur många VMs som kommer att vara igång samtidigt.

Tack så mycket för svar! Började fundera på om jag lagt tråden på fel ställe, kanske borde ligga under servrar istället?

Högst antal samtidiga virtuella servrar som är igång blir max 25st (i överkant), totalt antal servrar blir dock ca. 50st, och det är där problemet ligger, att skapa 50 servrar är inga större problem när det gäller RAM och CPU, lagringsmässigt är det en annan femma.
Med dedikerade switchar hoppas jag att du menar helt vanliga switchar men som bara sysslar med trafiken mellan lagring och servrar? Om det är så du menar så är det inga större problem, switchar finns, om än inga extraordinära (omanagerade Netgear- och D-link-switchar)...

Det totala lagringsutrymmet beräknas till 12x240GB SSD, alltså knappt 3TB.

Som sagt, vi har tillgång till en ML330 som var tänkt agera lagringserver tillsammans med DELL-disklådan, förmodligen kompletteras den servern med ett 4-portars nätverkskort (totalt 6x1Gb LAN).

En ny tanke som slog mig inatt var att helt enkelt försöka klustra de åtta fysiska servrarna, men jag vet inte om jag kan göra detta med enbart gratis ESXi (alltså utan vCenter eller liknande), här räcker inte mina kunskaper till längre :/ Annars får vi kanske gå över till Hyper-V istället, Windows-licenser har vi tillgång till så där behövs inga investeringar (att börja köpa Vmware-licenser är inget alternativ, vi har ytterst begränsad budget).

Permalänk
Medlem
Skrivet av cbtcp:

Tack så mycket för svar! Började fundera på om jag lagt tråden på fel ställe, kanske borde ligga under servrar istället?

Högst antal samtidiga virtuella servrar som är igång blir max 25st (i överkant), totalt antal servrar blir dock ca. 50st, och det är där problemet ligger, att skapa 50 servrar är inga större problem när det gäller RAM och CPU, lagringsmässigt är det en annan femma.
Med dedikerade switchar hoppas jag att du menar helt vanliga switchar men som bara sysslar med trafiken mellan lagring och servrar? Om det är så du menar så är det inga större problem, switchar finns, om än inga extraordinära (omanagerade Netgear- och D-link-switchar)...

Det totala lagringsutrymmet beräknas till 12x240GB SSD, alltså knappt 3TB.

Som sagt, vi har tillgång till en ML330 som var tänkt agera lagringserver tillsammans med DELL-disklådan, förmodligen kompletteras den servern med ett 4-portars nätverkskort (totalt 6x1Gb LAN).

En ny tanke som slog mig inatt var att helt enkelt försöka klustra de åtta fysiska servrarna, men jag vet inte om jag kan göra detta med enbart gratis ESXi (alltså utan vCenter eller liknande), här räcker inte mina kunskaper till längre :/ Annars får vi kanske gå över till Hyper-V istället, Windows-licenser har vi tillgång till så där behövs inga investeringar (att börja köpa Vmware-licenser är inget alternativ, vi har ytterst begränsad budget).

Jo förmodligen. Men skit i det :).

25 igång är ju en del. Det blir ju en del data. "helt vanliga" är ju en definitionsfråga. iSCSI är ganska intensivt. Skulle aldrig någonsin i hela mitt liv rekommendera varken D-Link eller Netgear till det (inte till något annat heller för den delen).
Jo men oavsett om du klustrar eller inte så behöver du centraliserad lagring. Det löser sig inte automagiskt för att du har vCenter. Hyper-V har kommit ganska långt och du kan säkerligen klara dig bra på det. Men som sagt, du behöver fortfarande lagring.
I ditt fall hade jag nog delat upp det på två. Kört en miljö med en hemmabyggt SAN och en identisk med hemmabyggt SAN igen. Dvs dela din miljö på hälften och offra två servrar för lagring.
Jag hade inte blandat in varken D-Link eller Netgear i något som har med drift att göra.

Permalänk
Medlem
Skrivet av cbtcp:

De virtuella servrarna lagras på konsument-SSD:er (240GB Corsair och Toshiba blandat) och här kommer problemet in, SSD:ernas utrymme används inte särskilt smart, det tenderar att bli utrymme som inte kan användas på dem.

Enligt leverantören behövs till disklådan en controller med externa portar (vi har fått som förslag HP H221) för att ansluta till en helt annan server vi har tillgång till (HP ML330) och därefter kan vi dra nytta av disklådan och köra JBOD genom den till en ZFS-maskin (inte helt bestämt OS o.s.v.).

Skrivet av cbtcp:

Högst antal samtidiga virtuella servrar som är igång blir max 25st (i överkant), totalt antal servrar blir dock ca. 50st, och det är där problemet ligger, att skapa 50 servrar är inga större problem när det gäller RAM och CPU, lagringsmässigt är det en annan femma.

Det totala lagringsutrymmet beräknas till 12x240GB SSD, alltså knappt 3TB.

Största problemet jag ser är... vf gör du när en av dessa konsument diskarna spottar fel? Med JBOD fördelar du inte lasten mellan dem jämt, utan vissa diskar kommer jobba mer än andra, och när en enda av dessa 12 rasar så har du problem... Tänk på att dessa SSDer endast fungerar optimalt med TRIM och OP, INTE i RAID/JBOD med 100% fyllningsgrad. Och med JBOD får ju första diskarna garanterat nära 100% väldigt fort.

Som du har det nu så går en disk ner går kanske en server ner med några VM, men resten kan hållas vid liv. Men ditt förslag låter väldigt riskabelt för så pass aktiv drift.

Även om du har tajt budget borde du kunna klämma fram lite till några 512GB SSDer. Du sa ju själv att CPU/RAM är inte problem, så lös lagrings problemet genom att utöka det. Sen sätt 2st 240GB diskar på vissa maskiner och lägg in 512GB på de andra, eller bygge en ny RAID av central lagring om du måste med typ RAID 10 eller liknande. Men inte JBOD på SSDer i den skalan

Backup antar jag att du har, men drifttid kan ni väl inte totalt ignorera heller, eller?

Permalänk
Inaktiv

Alltid lika intressant att se JBOD tolkning mot JBOD tolkning. Som i att vissa ser det som att allt slängs ihop till en enda array av mixade diskar. Medans andra ser det som Just A Bunch Of Disks som representeras individuellt till en host som sedan kan RAID dessa hur de själva vill.

Beroende på vad TS vill åstadkomma kan jag rekommenderas en av dessa för trevlig expansion down the line.

http://www.ebay.com/itm/201633427700

Permalänk
Medlem

Dags att utveckla för er om hur vi använder systemet:

Eleverna har varsin virtuell server (=2-3 elever/servrar per fysisk server)
Deras individuella, virtuella server används ca. 3h/dag
Om en fysisk server går ner (p.g.a. diskras eller liknande) återställs elevernas progression ytterst snabbt (inte ens backup är tvunget, även om det underlättar (senare projekt)).

Här kommer syftet till frågorna och önskemålet om tips:

Som det är just nu kan bara en klass lagra sin information (virtuella servar + snapshots). Detta beror enbart på att diskutrymmet per server "saknas" p.g.a. att utrymmet inte kan utnyttjas optimalt, varje fysisk server är som sagt begränsad till 240GB (SSD) där 2-3 virtuella servrar (inkl. snapshots) upptar ca. 70GB (i överkant), 70GBx3=210GB=mellan 30-60GB outnyttjad yta, dessa 30-60GB hade kunnat användas till andra virtuella servrar om alla diskar var RAID:ade (eller hur det ska lösas).

Vi vill skapa oss fysisk plats för en klass till (som dock inte jobbar samtidigt som den första klassen).
Ett par SSD:er (240GB) kommer att köpas in för att "täcka upp" det utrymme som saknas efter ovanstående ekvation.

Summa:
CPU, RAM räcker till (eftersom alla inte jobbar samtidigt)
Lagringsutrymme saknas för att kunna skapa fler virtuella servrar

Permalänk
Medlem

Som Paddanx är inne på, så ser jag inte JBOD som ett alternativ. Ni behöver antingen en "riktig" RAID lösning, så att alla diskarna får jobba effektivt, eller en "riktig" ZFS lösning, så att samma effekt uppnås. I båda fallen handlar det om samma sak. Inte att data skulle vara säkrare, utan att sprida ut läs, och framförallt skrivningarna till diskarna, så att ni dels håller prestandan uppe, men främst får jämnt slitage på alla enheterna, och inte dödar en i taget, för att det är den, de, ni skriver till mest.

FreeNAS / iSCSI ?
B!

Visa signatur

Allting jag skriver är om inget annat uttrycks, min åsikt! Ingenting måste vara dagens sanning enligt din åsikt, och gör du antaganden baserade på mina åsikter hoppas jag att du övervägt mer än bara just min åsikt.

Permalänk
Medlem

Skulle inte Vmwares vSAN vara ett alternativ?

dvs trycka in diskar i befintliga Hostar och köra lagringen där... jag har dock inte koll på hur det är med licenser osv

Visa signatur

.: Learn the system, Play the system, Break the system :.

Permalänk
Medlem
Skrivet av -=Mr_B=-:

Som Paddanx är inne på, så ser jag inte JBOD som ett alternativ. Ni behöver antingen en "riktig" RAID lösning, så att alla diskarna får jobba effektivt, eller en "riktig" ZFS lösning, så att samma effekt uppnås. I båda fallen handlar det om samma sak. Inte att data skulle vara säkrare, utan att sprida ut läs, och framförallt skrivningarna till diskarna, så att ni dels håller prestandan uppe, men främst får jämnt slitage på alla enheterna, och inte dödar en i taget, för att det är den, de, ni skriver till mest.

FreeNAS / iSCSI ?
B!

Det är FreeNAS/ZFS/iSCSI-lösningen vi har tänkt oss, om jag har fattat det rätt (kan vara helt ute o segla här) så är det just JBOD vi vill ha för att köra en ZFS-RAID, eller? Alltså, JBOD är en del av lösningen.

Skrivet av Mr_Lazy:

Skulle inte Vmwares vSAN vara ett alternativ?

dvs trycka in diskar i befintliga Hostar och köra lagringen där... jag har dock inte koll på hur det är med licenser osv

Det är här mina icke-kunskaper skiner igenom som mest, hur fungerar detta? Vilka kostnader medför det (om någon här vet)? Finns gratisalternativ? Våra pengar är ytterst begränsade...
När jag pratade om klustring var det ungefär så som du skriver jag önskade f.ö.

Permalänk
Medlem

JBOD är "Just a Bunch Of Drives". Controllern klumpar ihop dem till en enda enhet, och ZFS, och FreeNAS, eller RAID, är i det läget helt meningslöst. De ska köras direkt mot diskarna.
B!

Visa signatur

Allting jag skriver är om inget annat uttrycks, min åsikt! Ingenting måste vara dagens sanning enligt din åsikt, och gör du antaganden baserade på mina åsikter hoppas jag att du övervägt mer än bara just min åsikt.

Permalänk
Medlem
Skrivet av cbtcp:

Det är FreeNAS/ZFS/iSCSI-lösningen vi har tänkt oss, om jag har fattat det rätt (kan vara helt ute o segla här) så är det just JBOD vi vill ha för att köra en ZFS-RAID, eller? Alltså, JBOD är en del av lösningen.

Det är här mina icke-kunskaper skiner igenom som mest, hur fungerar detta? Vilka kostnader medför det (om någon här vet)? Finns gratisalternativ? Våra pengar är ytterst begränsade...
När jag pratade om klustring var det ungefär så som du skriver jag önskade f.ö.

Kostnad har jag inte koll på. Men här är svar på lite frågor
https://blogs.vmware.com/virtualblocks/2015/05/29/20-common-v...

Visa signatur

.: Learn the system, Play the system, Break the system :.

Permalänk
Medlem
Skrivet av cbtcp:

Det är FreeNAS/ZFS/iSCSI-lösningen vi har tänkt oss, om jag har fattat det rätt (kan vara helt ute o segla här) så är det just JBOD vi vill ha för att köra en ZFS-RAID, eller? Alltså, JBOD är en del av lösningen.

Det är här mina icke-kunskaper skiner igenom som mest, hur fungerar detta? Vilka kostnader medför det (om någon här vet)? Finns gratisalternativ? Våra pengar är ytterst begränsade...
När jag pratade om klustring var det ungefär så som du skriver jag önskade f.ö.

Det jag är mest rädd för är att du missförstår hur dessa konsument diskar mår när de fylls. Låt oss bryta ner "problemen" jag syftar på, så du kanske förstår varför jag tror att fler SSDer är bättre, än att fylla upp de ni har för mycket. Nu vet jag inte din kunskap om just SSD, så om det låter lite grundläggande så är det inte menat som nedlåtande, utan pga jag inte vet din kunskap om dem.

SSDer har visst antal celler, och problemet är att MLC, eller mer vanligare idag TLC skriver fler bit data per cell. De kan inte tömmas som individuella celler, utan måste tömmas som blocks av många celler. Så när du fyller dem >90% så är där brist på tomma celler typ hela tiden. Det innebär att för varje liten sektor som skrivs, måste ofta många andra celler läsas, och skrivas om för att sen kunna tömma de gamla blocksen. Detta gör att en enkel 1MB skrivning kan lätt börja ta både 4-5MB slitage, och Write Amplification factorn stiger mot taket, vilket kommer att snabbt riskera slita ut era diskar.

Finns två sätt att "fixa" detta problem. Ena är vad man gör med enterprise diskar, och det är att sätta enorm Over Provision utrymme. Mao.. man ger SSDn massor med ledigt utrymme att göra dessa rotationer på. Så en SSD med totalt 512GibiByte (ca 550GigaByte) rent fysiskt, säljs som en 480-500GB med 7-8% OP och lite extra för reservsektorer mm. Samma "disk" kommer dock säljas som 400GB disk för enterprise, men då med över 30% OP istället, vilket gör att den klarar av denna last.

Sen har vi den viktigaste grundtekniken som är ett måste för konsument SSDer idag, nämligen TRIM. Detta då vårt filsystem aldrig tar bort något.. utan den bara skriver om fil-tabellen att den sektorn är ledig, något en HDD inte bryr sig om, då den kan skriva om ny data rakt ovanpå den gamla. Eftersom en SSD dock aldrig kan skriva på det sättet så kommer den hålla kvar den datan, tills samma LBA adress skrivs om igen, eller ett TRIM kommando säger: "den sektorn är nu ledig" till SSDn direkt.

Utan TRIM mao, kommer disken aldrig kunna tömma dessa celler med gammal data, utan den kommer tom skriva om den som aktiv data när du skriver nytt, tills exakt den LBA adressen "skrivs på nytt". Först då kan den ta bort den gamla. Du kan tänka dig att skriva 1 byte till varje sektor på hela SSDn. Sen tar du bort alla i filsystemet. Du ser en tom disk... SSDn ser en 100% full disk och kan inte göra något.

Och problemet är... väldigt få RAID kontrollern och mjukvaror har fullt TRIM stöd. Vilket gör att SSDer i RAID ofta saknar detta, vilket ökar både slitage och sänker prestandan rejält med tiden, pga det jag beskrev ovan.

Problemet med en traditionell JBOD är ju att diskarna läggs en efter varandra, så de första 1-2 diskarna kommer att vara fulla nästa direkt, då det är så LBA adressering sker. Den SSDn som ligger sist i ledet kommer knappt se någon last alls, och troligen vara rätt tom.

Så min poäng är... SSDer ska inte fyllas helt och RAID/JBOD utan TRIM is bad, mkay?
Lite info kan du läsa här: http://www.anandtech.com/show/6489/playing-with-op

Sen kommer en motfråga jag undrar. Om ni nu har typ samma grund i flera WMs... varför kör ni inte parent och child VHDs? Du borde kunna köra en parent med system mm och på så sätt spara det mesta av systemets plats. Sen kommer ju varje elevs VHD att expandera efter behovet, och ni borde få mer effektiv plats.

Iden jag sa tidigare med att köpa in några 500(+)GB SSDer och trycka dubbelt (eller mer) av 240GB i de andra borde ändå vara en prisvärd lösning med minimalt jobb. Det kan också göra successivt, så köp en disk här och där på rea och sen bygg om en maskin med ny disk och en 240GB som extra disk i en annan. Lägg till parent och child VHD och du borde kunna få det att räcka länge då du bara har ett "system" att lagra som är samma för alla. Ändringarna lagras sen i en child VHD för varje elev.

Andra alt är ju att som andra föreslagit, göra en riktig lagrings server... men du måste då tänka på OP och TRIM, och slitage, annars kommer de konsument diskarna att sega ihop väldigt fort.

Förstår att pengar inte växer på träd och parent/child VM är ev ett gratis alt att få mer utrymme även ur befintliga diskar, men det blir ju inte gratis om du sliter sönder en massa SSDer heller...

Permalänk
Medlem
Skrivet av Paddanx:

Det jag är mest rädd för är att du missförstår hur dessa konsument diskar mår när de fylls. Låt oss bryta ner "problemen" jag syftar på, så du kanske förstår varför jag tror att fler SSDer är bättre, än att fylla upp de ni har för mycket. Nu vet jag inte din kunskap om just SSD, så om det låter lite grundläggande så är det inte menat som nedlåtande, utan pga jag inte vet din kunskap om dem.

SSDer har visst antal celler, och problemet är att MLC, eller mer vanligare idag TLC skriver fler bit data per cell. De kan inte tömmas som individuella celler, utan måste tömmas som blocks av många celler. Så när du fyller dem >90% så är där brist på tomma celler typ hela tiden. Det innebär att för varje liten sektor som skrivs, måste ofta många andra celler läsas, och skrivas om för att sen kunna tömma de gamla blocksen. Detta gör att en enkel 1MB skrivning kan lätt börja ta både 4-5MB slitage, och Write Amplification factorn stiger mot taket, vilket kommer att snabbt riskera slita ut era diskar.

Finns två sätt att "fixa" detta problem. Ena är vad man gör med enterprise diskar, och det är att sätta enorm Over Provision utrymme. Mao.. man ger SSDn massor med ledigt utrymme att göra dessa rotationer på. Så en SSD med totalt 512GibiByte (ca 550GigaByte) rent fysiskt, säljs som en 480-500GB med 7-8% OP och lite extra för reservsektorer mm. Samma "disk" kommer dock säljas som 400GB disk för enterprise, men då med över 30% OP istället, vilket gör att den klarar av denna last.

Sen har vi den viktigaste grundtekniken som är ett måste för konsument SSDer idag, nämligen TRIM. Detta då vårt filsystem aldrig tar bort något.. utan den bara skriver om fil-tabellen att den sektorn är ledig, något en HDD inte bryr sig om, då den kan skriva om ny data rakt ovanpå den gamla. Eftersom en SSD dock aldrig kan skriva på det sättet så kommer den hålla kvar den datan, tills samma LBA adress skrivs om igen, eller ett TRIM kommando säger: "den sektorn är nu ledig" till SSDn direkt.

Utan TRIM mao, kommer disken aldrig kunna tömma dessa celler med gammal data, utan den kommer tom skriva om den som aktiv data när du skriver nytt, tills exakt den LBA adressen "skrivs på nytt". Först då kan den ta bort den gamla. Du kan tänka dig att skriva 1 byte till varje sektor på hela SSDn. Sen tar du bort alla i filsystemet. Du ser en tom disk... SSDn ser en 100% full disk och kan inte göra något.

Och problemet är... väldigt få RAID kontrollern och mjukvaror har fullt TRIM stöd. Vilket gör att SSDer i RAID ofta saknar detta, vilket ökar både slitage och sänker prestandan rejält med tiden, pga det jag beskrev ovan.

Problemet med en traditionell JBOD är ju att diskarna läggs en efter varandra, så de första 1-2 diskarna kommer att vara fulla nästa direkt, då det är så LBA adressering sker. Den SSDn som ligger sist i ledet kommer knappt se någon last alls, och troligen vara rätt tom.

Så min poäng är... SSDer ska inte fyllas helt och RAID/JBOD utan TRIM is bad, mkay?
Lite info kan du läsa här: http://www.anandtech.com/show/6489/playing-with-op

Sen kommer en motfråga jag undrar. Om ni nu har typ samma grund i flera WMs... varför kör ni inte parent och child VHDs? Du borde kunna köra en parent med system mm och på så sätt spara det mesta av systemets plats. Sen kommer ju varje elevs VHD att expandera efter behovet, och ni borde få mer effektiv plats.

Iden jag sa tidigare med att köpa in några 500(+)GB SSDer och trycka dubbelt (eller mer) av 240GB i de andra borde ändå vara en prisvärd lösning med minimalt jobb. Det kan också göra successivt, så köp en disk här och där på rea och sen bygg om en maskin med ny disk och en 240GB som extra disk i en annan. Lägg till parent och child VHD och du borde kunna få det att räcka länge då du bara har ett "system" att lagra som är samma för alla. Ändringarna lagras sen i en child VHD för varje elev.

Andra alt är ju att som andra föreslagit, göra en riktig lagrings server... men du måste då tänka på OP och TRIM, och slitage, annars kommer de konsument diskarna att sega ihop väldigt fort.

Förstår att pengar inte växer på träd och parent/child VM är ev ett gratis alt att få mer utrymme även ur befintliga diskar, men det blir ju inte gratis om du sliter sönder en massa SSDer heller...

Tack för ett ytterst informativt och pedagogiskt svar! Jag är någorlunda medveten om problemen med konsument-SSD:er, TRIM, OP o.s.v., dock mindre koll på siffrorna/procenten du nämner så specifikt (väldigt informativt som sagt!).

Kan du berätta lite mer om det du nämner om parent/child? Det du skriver låter Microsoft-associerat, eftersom du nämner VHD menar jag...
Har ingenting emot att byta hypervisor om det behövs även om det skapar lite merjobb.

P.s. har fått ett annat förslag från leverantören om en beggad server, Supermicro SC826 2xE5620, SAS/RAID 3ware 9750-4i, 12x2.5" som vi tyckte såg intressant ut, någon som vill uttala sig framförallt om RAID-kortet? Kan det vara ett bra alternativ för en ZFS-RAID (eller hårdvaru-RAID)? Gillar tanken på ZFS:s deduplication.
Servern skulle användas som lagringsserver alltså

Permalänk
Medlem
Skrivet av cbtcp:

Kan du berätta lite mer om det du nämner om parent/child? Det du skriver låter Microsoft-associerat, eftersom du nämner VHD menar jag...
Har ingenting emot att byta hypervisor om det behövs även om det skapar lite merjobb.

Det borde vara samma funktion som VMware kallar "linked clone", men i så fall måste jag säga att jag inte tycker det är en bra lösning på system som ska leva "längre" tider. Jag vet inte varför, men åtminstone just för VMware blir prestandan lidande över tid. Rätt kraftigt.

Skrivet av cbtcp:

Kan det vara ett bra alternativ för en ZFS-RAID (eller hårdvaru-RAID)?

Eftersom burken kommer med ett 3ware 9750-4i så är det rimligtvis inte ett JBOD chassi, och de 12 diskarna borde vara tillgängliga. Jag vet inte om det går att flasha om det RAIDkortet till en HBM, eller om funktionaliteten finns inbyggd. Annars är det "fel" kort för ett ZFS bygge. Eftersom det är en 4 kanals controller, med expander till 12 diskar, så blir hastigheten lite begränsad. Det borde inte vara ett problem, 6gB/s / kanal, och rimligtvis 3 diskar per kanal.
3ware brukar anses vara en "bra" tillverkare, men jag har inte använt det här RAIDkortet.
B!

Visa signatur

Allting jag skriver är om inget annat uttrycks, min åsikt! Ingenting måste vara dagens sanning enligt din åsikt, och gör du antaganden baserade på mina åsikter hoppas jag att du övervägt mer än bara just min åsikt.

Permalänk
Medlem
Skrivet av -=Mr_B=-:

Det borde vara samma funktion som VMware kallar "linked clone", men i så fall måste jag säga att jag inte tycker det är en bra lösning på system som ska leva "längre" tider. Jag vet inte varför, men åtminstone just för VMware blir prestandan lidande över tid. Rätt kraftigt.

Ja, linked clone släppte jag direkt, om inte annat för att det var rejält krångligt när man "bara" körde ESXi/vSphere.

Skrivet av -=Mr_B=-:

Eftersom burken kommer med ett 3ware 9750-4i så är det rimligtvis inte ett JBOD chassi, och de 12 diskarna borde vara tillgängliga. Jag vet inte om det går att flasha om det RAIDkortet till en HBM, eller om funktionaliteten finns inbyggd. Annars är det "fel" kort för ett ZFS bygge. Eftersom det är en 4 kanals controller, med expander till 12 diskar, så blir hastigheten lite begränsad. Det borde inte vara ett problem, 6gB/s / kanal, och rimligtvis 3 diskar per kanal.
3ware brukar anses vara en "bra" tillverkare, men jag har inte använt det här RAIDkortet.
B!

Dealade med leverantören en smula, fick byta 3ware-kortet till ett LSI (9211-8i) flashat i IT-mode + lite mer internminne för samma pengar (misstänker att 3ware-kortet betingar ett högre värde så leverantören loosar förmodligen inte ett smack), 3ware-kortet var inte särskilt lämpligt för ZFS (HBA var inget alternativ). Glömde dock fråga om LSI-kortet faktiskt funkar till expandern :/
Servern beställs imorrn under förutsättning att kortet funkar till expandern...

Testar parent/child genom Hyper-V fr.o.m. för någon timme sen, lite drygt att bara kunna testa det mot mekaniska diskar (testar via vår ML330G6:a som bara har två 500GB SATA HDD:s nu, inte ens RAID0 ökar hastigheten nämnvärt, örk!).
Grund-VHDx:en är skapad nu åtminstone
Planen är då att lägga parent- och child VHDx:erna på "nya" servern (när den kommer) som i sin tur kör FreeNAS+ZFS+iSCSI (om ingen har bättre förslag?).

Några följdfrågor jag hoppas någon guru kan svara på:
Hur många kanaler har LSI-kortet, kommer det att bli hastighetsproblem mot diskarna?
Någon som har erfarenhet av link aggregation i FreeNAS för (eventuell hastighetsökning)? Är det ens lönt?
Vi har fått erbjudande om en HP-switch (Procurve 2848-48) för ca. 1500:-, kommer den att orka hantera trafiken (och stödja LACP ordentilgt)?
Funkar NIC-teaming i Windows på samma sätt som LACP? Bara ett annat namn kanske?

Jodå, jag vet att jag säkert kan hitta många svar på nätet men just nu snurrar det bara i skallen och allt är rörigt...

Permalänk
Medlem
Skrivet av cbtcp:

Några följdfrågor jag hoppas någon guru kan svara på:

Långt från Guru, men jag försöker lite i alla fall, hoppas det går bra?

Skrivet av cbtcp:

Hur många kanaler har LSI-kortet, kommer det att bli hastighetsproblem mot diskarna?

8. Prestandan beror mer på bakplanet än på kortet. Jag blir inte jätteförvånad om backplanet bara tar en tåt från kontroller kortet, alltså, 4 kanaler.

Skrivet av cbtcp:

Vi har fått erbjudande om en HP-switch (Procurve 2848-48) för ca. 1500:-, kommer den att orka hantera trafiken (och stödja LACP ordentilgt)?

Orka trafiken... Tja, det BORDE den göra. Problemet blir nog att få lagringsservern att orka med. Men så är det alltid. LACP. Det SKA fungera.

Skrivet av cbtcp:

Funkar NIC-teaming i Windows på samma sätt som LACP? Bara ett annat namn kanske?

LACP är NIC-teaming, men NIC teaming är mer än LACP. (LACP är protokoll/standard specifikt, 802.1AX, medan NIC-teaming lite skiter i vilket... Det viktiga för dig är att det ska fungera ihop. Ska.)

B!

Visa signatur

Allting jag skriver är om inget annat uttrycks, min åsikt! Ingenting måste vara dagens sanning enligt din åsikt, och gör du antaganden baserade på mina åsikter hoppas jag att du övervägt mer än bara just min åsikt.

Permalänk
Medlem
Skrivet av -=Mr_B=-:

Långt från Guru, men jag försöker lite i alla fall, hoppas det går bra?

För mig skulle du kunna vara Jesus Ytterst tacksam för dina svar!!!

Skrivet av -=Mr_B=-:

8. Prestandan beror mer på bakplanet än på kortet. Jag blir inte jätteförvånad om backplanet bara tar en tåt från kontroller kortet, alltså, 4 kanaler.

Då är jag med, bakplanet utgår jag ifrån att man inte kan göra något åt...

Skrivet av -=Mr_B=-:

Orka trafiken... Tja, det BORDE den göra. Problemet blir nog att få lagringsservern att orka med. Men så är det alltid. LACP. Det SKA fungera.

Anade det svaret

Skrivet av -=Mr_B=-:

LACP är NIC-teaming, men NIC teaming är mer än LACP. (LACP är protokoll/standard specifikt, 802.1AX, medan NIC-teaming lite skiter i vilket... Det viktiga för dig är att det ska fungera ihop. Ska.)

B!

Jahopp, då har man blivit lite klokare gällande teaming/LACP

Får man fråga vad Mr.B jobbar med?

Permalänk
Medlem
Skrivet av cbtcp:

För mig skulle du kunna vara Jesus Ytterst tacksam för dina svar!!!

Jag har försökt med att gå på vatten. Det funkar inte, man blir bara blöt. Så här vintertid går det att fuska, men det är inte riktigt samma sak...

Skrivet av cbtcp:

Då är jag med, bakplanet utgår jag ifrån att man inte kan göra något åt...

Mja... Det GÅR så klart att byta ut. Men då ska man hitta ett som passar, eller flera, och jag är inte riktigt säker på vad man ska förvänta sig där. Det är bara 12 diskar, så hur man än gör blir det inte riktigt bra med 8'a kanaler, medan 4 blir tre diskar vardera. Man kan inte köra 1,5 diskar per kanal menar jag.

Skrivet av cbtcp:

Får man fråga vad Mr.B jobbar med?

Visst får man. Den killen känner jag inte, så jag kan inte svara på det.
Själv jobbar jag inte. Det ser så fattigt ut. Av det arroganta svaret borde de flesta lista ut att jag är sjuk i huvudet, och alltså, sjukpensionär. Det är bra för fritiden, mindre bra för ekonomin, men det går inte direkt någon nöd på mig. Det är något av en prioriteringsfråga, antar jag.
B!

Visa signatur

Allting jag skriver är om inget annat uttrycks, min åsikt! Ingenting måste vara dagens sanning enligt din åsikt, och gör du antaganden baserade på mina åsikter hoppas jag att du övervägt mer än bara just min åsikt.

Permalänk
Medlem

Sent svar men...

Skrivet av cbtcp:

Kan du berätta lite mer om det du nämner om parent/child? Det du skriver låter Microsoft-associerat, eftersom du nämner VHD menar jag...
Har ingenting emot att byta hypervisor om det behövs även om det skapar lite merjobb.

Skrivet av -=Mr_B=-:

Det borde vara samma funktion som VMware kallar "linked clone", men i så fall måste jag säga att jag inte tycker det är en bra lösning på system som ska leva "längre" tider. Jag vet inte varför, men åtminstone just för VMware blir prestandan lidande över tid. Rätt kraftigt.

Visst riskerar det bli prestanda nackdelar, men notera dock, du jobbar mot SSD. En HDD kommer ju få söka och jobba mot två ställen, vilket sänker prestandan ytterliggare, men för en SSD ligger redan all data huller om buller så, prestanda skillnaden borde inte bli så illa.

@cbtcp nämner också flera gånger att prestanda är inte problemet, utrymme är, så det var en uppoffring som trots allt inte kostar "ny hårdvara nu".

Det skulle mao, i teorin iaf, kunna ge dig lite mer tid att ordna en vettig lagrings lösning, och lösa en del av problemet tillfälligt iaf tills du har en. Var inte tänkt som en permanent lösning, även om den går att använda i långa loppet om man bara har struktur och plan på hur man ska göra.

Förstår dock om du inte vill gå den vägen. Var ett förslag iaf

Skrivet av cbtcp:

För mig skulle du kunna vara Jesus Ytterst tacksam för dina svar!!!

Får man fråga vad Mr.B jobbar med?

Ingen vet vem han är, men jag vet att han kan saker
Han har gett goda råd många gånger så tvivlar inte på honom själv iaf.

Skrivet av -=Mr_B=-:

Jag har försökt med att gå på vatten. Det funkar inte, man blir bara blöt. Så här vintertid går det att fuska, men det är inte riktigt samma sak...

B!

Minns du gillade bilar... har du inte sett mythbusters som lyckades köra en motorcrosscykel på vatten? Har även sett extrem NOS bestyckade bilar som lyckats "hoppa groda" på vatten...

Så du behöver bara springa lite fortare

Permalänk
Medlem
Skrivet av Paddanx:

Visst riskerar det bli prestanda nackdelar, men notera dock, du jobbar mot SSD. En HDD kommer ju få söka och jobba mot två ställen, vilket sänker prestandan ytterliggare, men för en SSD ligger redan all data huller om buller så, prestanda skillnaden borde inte bli så illa.

Jag säger inte att jag vet något om andra plattformer, men VMware workstation, blir långsammare, på SSD, ju mer klonen skiljer från originalet. Jag har fått för mig att det är för att filsystemet blir mer och mer komplicerat, men det är inte något jag fått verifierat någonstans.

Skrivet av Paddanx:

@cbtcp nämner också flera gånger att prestanda är inte problemet, utrymme är, så det var en uppoffring som trots allt inte kostar "ny hårdvara nu".

Det är iofs sant. Och sen är det ju en fråga om hur stora skillnader det hinner bli på "originalet" och klonen, innan man helt enkelt skapar en ny, för att arbetsuppgifterna inte behöver den gamla. Pratar vi OS uppdateringar osv så är det ju "nollställt" igen så fort man gör en ny klon.

Skrivet av Paddanx:

Ingen vet vem han är, men jag vet att han kan saker
Han har gett goda råd många gånger så tvivlar inte på honom själv iaf.

Låter som en hyvens kille.

Skrivet av Paddanx:

Om vi helt bortser från att jag som medelålders man, nog är ganska stereotypisk, alltså, lite överviktig, vit, tunnhårig, osv, så är jag även lat. Springa är kanske inte överst på listan av grejer jag tänker göra i det närmaste. För övrigt så har Mythbusters provat det där med springa med. Det gick så där. Jag hittar inte några klipp där de har den kvinnliga atleten till att springa, men de provade rent av med "större fötter", "svans", och grejer, för att efterlikna någon jesus-ödla, som kan springa på vatten. Det hjälpte inte det i heller. Och kan inte hon, som är både lättare och snabbare än jag klara det, så ska jag nog hålla mig på grunt vatten där jag bottnar.
B!

Visa signatur

Allting jag skriver är om inget annat uttrycks, min åsikt! Ingenting måste vara dagens sanning enligt din åsikt, och gör du antaganden baserade på mina åsikter hoppas jag att du övervägt mer än bara just min åsikt.