11 berichten aan het bekijken - 1 tot 11 (van in totaal 11)
  • Q:
    Bijdrager
    Pivni Pes

    Ruimte gebrek mailserver

    Ik heb een mailserver draaien op 2 schijven van 135GB 15K in RAID 1 configuratie.
    Het probleem wat er nu afspeelt is dat mijn mailserver vandaag op zijn kont lag in verband met te weinig ruimte.
    Nu ben ik al even wat ruimte aan het maken, maar uiteindelijk moet er 2 grotere nieuwe schijven in de mailserver worden geplaatst.

    Het punt is dat de huidige schijven 15K zijn, dus lekker rap, maar prijzig.
    Als ik 2 schijven van 7200rpm in de mailserver plaatst, merk ik dit dan aan snelheid?
    Is het een stuk trager, of maak ik mezelf druk om onzin?

    Bijdrager
    janverweij

    je zult het merken, afhankelijk van het aantal gebruikers. De accesstime zal trager worden, de doorvoer wordt ook trager, maar maakt voor de mailserver wat minder uit als er neit te veel gebruikers zijn.

    Bijdrager
    Pivni Pes

    Er zijn tussen de 6 en 8 gebruikers + 3 gebruikers met een iPhone.
    Volgens mijn zijn dit bij elkaar niet zoveel gebruikers.
    Wat zijn veel gebruikers, 50, 100?

    Bijdrager
    borisboef

    Daar ga je echt niets van merken. Heb hier setups gezien met 400 gebruikers op 7200-array RAID5.
    Uiteraard kun je altijd 15k verkiezen als je er het budget voor hebt, maar laten we zeggen voor tot de 30 gebruikers is er echt weinig verschil te merken. Hangt natuurlijk wel een beetje af van hoe je de mail benadert (webmail, IMAP, etc.) en of je veel zoekt en versleept, grote bestanden heen en weer mailt, 20 of 2000 mailtjes per dag hebt per gebruiker. Maar zou je daar geen zorgen over maken nu; knal er lekker een paar grote 7200 schijven in en je kunt weer vooruit.

    Bijdrager
    Pivni Pes

    Mooi, dan kan ik naar 2 1TB schijven gaan kijken;-)
    Bedankt voor jullie antwoorden tot zover.

    Op dit moment ben ik wat oude snapshots aan het verwijderen om mijn mail server weer aan de gang te krijgen, allen dat lukt nog niet klaarblijkelijk.

    Dus ik zat met vShere (mailserver draait virtueel op VMWare ESXi) te kijken naar wat instelingen.
    Bij de instellingen van mijn Zimbra-server zag ik staan: Disk file “[MAIL] Zimbra-server/Zimbra-server-000004.vmdk”

    En als ik kijkt met de datastore browser, dan zie ik 4 van zulke bestanden staan.
    – Zimbra-server.vmdk /3,3GB
    – Zimbra-server-000001.vmdk / 29,2GB
    – Zimbra-server-000003.vmdk / 97,8GB
    – Zimbra-server-000004.vmdk / 3,1GB

    Begrijp ik het goed dat “Zimbra-server-000004.vmdk” disk file is waarop mijn mail server draait, en dat de rest oude disk files zijn?
    De gemodificeerde datums van de 3 oudste zijn van de 6de maand 2011
    Kan ik deze ongestraft verwijderen, of is het dan gedane zaak met mijn mailserver?

    Bijdrager
    Pivni Pes

    Geen bestand verwijdert, maar verplaatst naar een andere storage, hierdoor raakte de mailserver corrupt.
    Dus verwijderen mag niet zomaar, dit komt omdat er toch een onderlinge verbinding is.
    Ik heb het bestand terug gezet, en via SSH maak ik een nieuwe thin vmdk bestand aan.
    Mailserver draait bijna weer, maar dan tijdelijk op de fileserver storage, maandag nieuwe schijven regelen, en de boel weer terug zetten;-)

    Het probleem is een soort van opgelost.

    Hoogstwaarschijnlijk worden het 2 Seagate 2TB 7200rmp schijven met SAS aansluiting.
    Op dezelfde aansluiting kan ik ook gewoon SATA schijven aan prikken, ik denk dat SAS misschien beter is.

    Bijdrager
    iep

    In dat geval wordt het verhaal totaal anders. Dan zitten de disks waarschijnlijk in de ESXi doos en staat hier de datastore op. In dat geval lever je wel wat in op sequentiële snelheid als je van 15k naar 7200rpm gaat, verder zal alles wel ongeveer hetzelfde zijn qua performance. Je kunt eventueel nog een ssd toevoegen als een soort van cache. Beetje idee wat ZFS doet (L2ARC).

    De losse bestanden die je ziet behoren allemaal tot dezelfde vmdk en zijn daarmee dan ook zeer cruciaal voor je vm (kijk maar eens naar de kolom “provisioned size” en tel de sizes die in de kolom “size” staan maar eens bij elkaar op en reken wat overhead mee). Knoei hier mee en je vm is stuk. Je kunt er ook alleen mee knoeien wanneer de vm uit of op suspend is gezet. Dat geldt ook voor het verplaatsen en kopiëren van vm’s.

    Het groter maken van virtuele machines wat schijfruimte betreft is vrij simpel. Je zult eerst de vm uit moeten zetten zodat je daarna in de instellingen de disk qua grootte kunt aanpassen. Als dat klaar is kan de vm weer aan en zul je in het OS wat in de vm draait middels de normale tools de schijfruimte aanpassen.

    Overigens is het verschil tussen sas en sata vandaag de dag niet zo erg groot meer.

    Nog een tip: je kunt de virtuele disk ook een independent disk maken. Als je dit instelt worden snapshots en de daadwerkelijke disk van elkaar gescheiden zodat ze geen invloed op elkaar hebben.

    Bijdrager
    Pivni Pes

    Ik was er inderdaad achter gekomen dat ik niet zomaar 1 van de 4 VMDK bestanden kon verwijderen.
    Toe ik er 1 had verplaatst naar een ander storage, was het hele gebeuren echt corrupt.
    Probleem was ook dat de VMDK Thick was, dus ik kon hem niet zomaar vergroten.
    Via Google had ik een oplossing via SSH gevonden, en via een commando heb ik de 4 VMDK bestanden opnieuw als 1 VMDK en thin laten opbouwen naar een andere storage.
    Hierna starten de mail server zonder problemen op.

    In mijn server heb ik 6 schijven, 2x 15k SAS 43GB in RAID 1, op deze zet heb ik 1 storage draaien met een Ubuntu test server.
    2x 15k SAS schijven van 146GB in RAID 1 met 1 storage met de Zimbra mail server, deze is nu leeg en moet worden vervangen voor groter (iets van 500GB … 1TB)
    2x 7,2k SATA schijven van 1TB in RAID 1 met 1 storage fileserver, en op dit moment staat daar ook tijdelijk de storage van de mail server op.
    Ik wil dus per set 1 storage draaien, nu is mij al gezegd dat ik anders moet denken, en dat ik meerderen storages kan draaien per set, en zelfs versplintert.
    Maar goed, ik ben misschien eigenwijs, en ik kies toch voor 1 storage per set.

    Nu heb ik nog geen schijven besteld, vandaag zeer druk geweest.
    Misschien wel goed geweest, wat ik lees nu pas je reactie, en ik begin nu te twijfelen tussen de 7,2k en de 15k schijven.

    Ook is het stukje SSD voor de cache wel interessant.
    Begrijp ik je goed alle bestanden op de SSD te zetten, zoals bijvoorbeeld de swap file, met uitzondering de VMDK bestanden?

    Dan zal ik de 2 schijven van de test server moeten verwijderen om daar de SSD in te plaatsen.
    De storage van de test server kan ik natuurlijk op op een van de 2 andere storages zetten.
    Deze server draait alleen maar als ik wat gaat uittesten, dus dan zit deze server niet iets anders in de weg.
    Moet ik dan 1 SSD plaatsen, of is het beter om er 2 te plaatsen in RAID 1 config?
    Of kan ik dan beter 2 plaatsen als RAID 0 en daar ook mijn snapshots op draaien?

    Hieronder de schijven waar enigszins mijn oog op gevallen is.
    Tussen de 7,2k en 15k zit een behoorlijk prijs verschil, bijna x3.

    SSD 120/128GB

    SAS 7200 rmp (Seagate Constellation)

    SAS 15k (Seagate Cheetah)

    Bijdrager
    iep

    Je kunt in ESXi een ssd als cache toewijzen voor de datastores. De optie heet Host Cache Configuration en wordt in ieder geval gebruikt als plek waar vm’s naar kunnen swappen. Dat vmfs is iets wat gebruikt wordt als filesystem en wat erg veel kan. Kijk eens verder of je daar niet wat mee kunt.

    Qua storage is het een keuze die je maakt. Je hebt nu eigenlijk een setup gekozen waarbij je iedere vm op z’n eigen schijf zet die dan redundant is uitgevoerd vanwege raid1. Je kunt er ook voor kiezen om er 1 array van te maken maar gezien de verschillende soorten disks is dat weer niet aan te raden (sas, sata, andere snelheden, andere capaciteiten). Een andere mogelijkheid die je bijv. voor de fileserver kunt gebruiken is een aparte raid kaart met daaraan wat schijven die je dan in ESXi middels VT-D doorstuurt (passthrough) aan de fileserver vm. Het kan natuurlijk nooit kwaad om nog eens goed naar je huidige setup qua storage te kijken om te zien of je daar niet wat kunt verbeteren op gebied van performance en betrouwbaarheid.

    Snapshots op snelle storage heeft alleen nut bij het aanmaken en verwijderen. Voor de rest win je er niks bij. De vmdk’s, swap e.d. op snelle storage heeft altijd baat omdat die wel veelvuldig van de snelle storage gebruik zal maken (lees: veel i/o activiteit).

    De vmdk’s als thin provisioned aanmaken scheelt ook wel wat aan schijfruimte omdat ESXi dan weet dat ie de rest gewoon kan gebruiken voor andere vm’s. Zo kun je wat efficiënter met diskspace omgaan.

    Ik denk dat je het beste af bent om eerst eens je huidige storage kritisch onder de loep te nemen. Kijk vanuit de vm: wat heeft die nodig en wat is daar de beste oplossing voor. Is het handig om het allemaal in een vmdk te doen of is een raid kaart middels passthrough een beter plan (performance bijv.)? Wordt er efficiënt met ruimte omgesprongen (hoe makkelijk kun je vm’s qua diskruimte vergroten/heen en weer schuiven van datastore naar datastore)? Hoe zit het met betrouwbaarheid, hoeveel disks kunnen er nu uitvallen en wat voor gevolgen heeft dat? Is het uberhaupt wel zo handig om alle storage in de ESXi machine te hebben of is een SAN/NAS die middels NFS aan de ESXi machine wordt gekoppeld niet beter (in de toekomst kun je op die manier vMotion gebruiken als je naar meer dan 1 ESXi machine gaat)?

    Bovenstaand zijn zomaar wat vragen die ik even afschiet maar waarvan ik denk dat je daar wel wat aan hebt. Zie het niet als een uitnodiging om een hele ingewikkelde setup te maken met NFS en vMotion want je zult echt moeten kijken naar waar jullie het voor gebruiken en voor willen gebruiken. Stem daar op af.

    Op vmug.nl vindt je ook aardig wat resources over ESXi (bij VMware obviously natuurlijk ook)

    Bijdrager
    Pivni Pes

    Beste Iep, bedankt voor deze zeer uitgebreide uitleg.
    Aangezien ik in de planning hebt om de huidige server over ± 1,5 jaar te vervangen voor een nieuwe, laat ik de huidige configuratie ongewijzigd.
    Uiteraard met uitzondering van de 2 nieuwe schijven voor de mail server.
    Met de nieuwe server moet ik alles een goed onder de loep nemen met wat op dat moment qua techniek speelt en wat mogelijk is.
    Wellicht dat ik ESXi nog wel upgrade naar versie 5, maar aan de andere kant, 4.1 draait perfect.

    Bijdrager
    iep

    Wellicht dat het volgende handig is om te bepalen of het waard is om te upgraden van 4.1 naar 5.0: VMware ESXi/ESX 4.1 and ESXi 5.0 Comparison.

11 berichten aan het bekijken - 1 tot 11 (van in totaal 11)

Je moet ingelogd zijn om een reactie op dit onderwerp te kunnen geven.