Virtuele shared storage oplossing

[vmsw]

Hetgeen ik zoek
Een oplossing voor bestandsopslag welke gebruikt kan op/door de applicatieservers.

In deze oplossing wil ik dat er een failover mogelijkheid is in het geval van een (hardware)storing of onderhoud. Uiteraard snap ik dat er een synchronisatieverschil is bij plotseling overschakelen.

Bij voorkeur implementeer ik dit middels een (virtuele) software-oplossing. Ik overweeg in toekomst HP VSA (virtuele SAN t.b.v. iSCSI) te gebruiken als opslag voor de virtuele machines. Deze zou in dat geval alle SSD's en HDD's beschikbaar krijgen.

Relevante onderdelen van omgeving (in datacentrum)

• 4 virtualisatie-servers op basis van Proxmox, KVM, voorzien van (ruim) SSD's (hardware RAID10)
• 1 Synlogy NAS voorzien van (ruim) HDD's (hardware RAID10)
• 8 virtuele applicatie-servers (Linux: zowel Debian als Ubuntu) welke de bestandsopslag nodig hebben
• 10GB netwerk

Globale werking
De applicatieservers worden willekeurig aangeroepen door een reverse-proxy (redundancy & load balancing), dus alle applicatieservers gebruiken 'willekeurig' data van de bestandsopslag. Het is dus niet zo dat bepaalde bestanden bij een bepaalde applicatieserver horen.

In principe kan de gebruikte applicatie gebruik maken van alle filesystems die regulier 'gemount' kunnen worden.

Huidige oplossing
Eén virtuele FreeNAS met lokale SSD-opslag geeft de 8 applicatieservers toegang tot de bestanden middels NFS. De server kan het prima aan. Reden dat ik overweeg deze oplossing te wijzigen is:

• Er is vooralsnog geen (lokale) failover-mogelijkheid aanwezig
• FreeNAS adviseert niet te virtualiseren, al helemaal niet op KVM zoals wij doen
• FreeNAS moet nodig updates krijgen en komt schijfruimte tekort, maar downtime is vervelend. Kortom: een mooi moment voor het implementeren van een betere oplossing.

[Verwijderd]

Ik denk dat je, met een 100% UX omgeving, helemaal geen slechte keuze hebt gemaakt met NFS. Natuurlijk zou je ook iSCSI kunnen gaan gebruiken, maar noodzakelijk is het niet. Een goede HA NFS oplossing zou ook prima kunnen werken.

Aangezien je aan het kijken bent naar een SDS oplossing van HP, ga ik er voor het gemak even vanuit dat er budget is. Dan zou je ook kunnen kijken naar de SDS oplossing van NetApp: ONTAP Select. Daarmee kun je virtuele ONTAP clusters bouwen. Met een 2-node (of meer) is in principe geen downtime meer nodig voor maintenance. Dat gaat allemaal non disruptive.

Ik ben voor block storage echt geen grote voorstander van NetApp, maar NFS... prima. Je zou natuurlijk ook gewoon naar een NetApp FAS HA-pair kunnen kijken (2 controllers met shared disks), maar het zou me niet verbazen als het prijskaartje een drempel gaat zijn.

[ Voor 11% gewijzigd door Verwijderd op 06-02-2018 13:29 ]

[DukeBox]

En iSCSI via je synology ? Al dan niet redundant uitgevoerd met een 2e ?

[Verwijderd]

DukeBox schreef op dinsdag 6 februari 2018 @ 13:32:
En iSCSI via je synology ? Al dan niet redundant uitgevoerd met een 2e ?

Dat wordt wel een kleine uitdaging. Je Synology is maar 1 systeem en deze zal down moeten voor bijvoorbeeld een DSM update. Dan zul je er dus een tweede naast moeten zetten en gaan repliceren. Maar dan heb je dus niet 1 disk met 4 paden, maar 2 disks met ieder 2 paden. En het mooiste zou toch zijn dat je storage patform zelf gaat bepalen wanneer een failover plaats gaat vinden.

Daarnaast zul je altijd "iets" nodig hebben die je iSCSI storage HA aan gaat bieden aan je servers. Gewoon 8 initiators in laten loggen op 1 iSCSI target LUN gaat 'm doorgaans niet worden.

[ Voor 14% gewijzigd door Verwijderd op 06-02-2018 14:17 ]

[DukeBox]

Verwijderd schreef op dinsdag 6 februari 2018 @ 14:13:
Dat wordt wel een kleine uitdaging. Je Synology is maar 1 systeem en deze zal down moeten voor bijvoorbeeld een DSM update.

Dat is geen probleem, ik heb heel was syno's met vphere draaien, zolang je het op een rustig IO moment doet kan je gewoon herstarten.

Dan zul je er dus een tweede naast moeten zetten en gaan repliceren. Maar dan heb je dus niet 1 disk met 4 paden, maar 2 disks met ieder 2 paden.

Nee, een syno in HA doet een failover, de units staan active/passive. De 4 paden blijven 4 paden alleen naar de andere synology welke online komt met dezelfde IP's.

Daarnaast zul je altijd "iets" nodig hebben die je iSCSI storage HA aan gaat bieden aan je servers. Gewoon 8 initiators in laten loggen op 1 iSCSI target LUN gaat 'm doorgaans niet worden.

Dat kan wel degelijk maar de initiator moet uiteraard wel clustering ondersteunen. Anders gaat dat met NFS en andere oplossingen ook niet werken. Debian ondersteund (net als alle andere *nix varianten) ook gewoon shared storage met iSCSI. NFS ondersteund tegenwoordig ook MP maar zover ik weet doet syno dat nog niet. Daarnaast mis je dan veel offload/acceleration opties.

[ Voor 29% gewijzigd door DukeBox op 06-02-2018 14:27 ]

[mortal]

Op mijn werk gebruiken wij voor dit soort "budget" redundante oplossingen hyper-v replica's. Beide servers zijn voorzien van genoeg memory en storage (local) om alle vm's te kunnen draaien.

Binnen hyper-v kan je (met de gratis hyper-v) vm replica's maken naar de andere host. Deze replica kan je elke 5,10 of 15 minuten laten lopen en zorgt daar mee dat er altijd een recente clone van de vm beschikbaar is op de andere host voor disaster doeleinden.

Ook kan je (met de gratis hyper-v) vm's live migreren van host naar host (op local storage) voor onderhoud.

voordelen:
geen dure shard storage san systemen
geen dure 10gbit san switches
geen dure high availability licentie
snelle local storage (bijvoorbeeld nvme)

[DukeBox]

mortal schreef op dinsdag 6 februari 2018 @ 14:30:
Op mijn werk gebruiken wij voor dit soort "budget" redundante oplossingen hyper-v replica's.

Kan opzich prima werken alleen debian wordt niet (heel slecht) gesupport.

[DennusB]

DukeBox schreef op dinsdag 6 februari 2018 @ 14:34:
[...]

Kan opzich prima werken alleen debian wordt niet (heel slecht) gesupport.

Ze doen het op block niveau, dus het maakt niet echt uit wat voor OS er op draait voor zover ik weet.

[DukeBox]

@DennusB Het default filesystem wordt al niet ondersteund van debian voor live migratie/copy, dan moet je al weer naar riser o.i.d. kijken wat weer vanuit debian niet (meer) ondersteund is. Het is gewoon geen fijne oplossing als je in de problemen raakt. KVM is dan een veel betere keuze en bied eigenlijk dezelfde mogelijkheden.

Domweg alleen op block niveau een kopie maken is gewoon gokken met je data.

Zie https://docs.microsoft.co...rtual-machines-on-hyper-v

[ Voor 8% gewijzigd door DukeBox op 06-02-2018 14:41 ]

[mortal]

mogelijk dat KVM het inderdaad kan. Maar een volledige HA omgeving vereist nou eenmaal erg dure SAN oplossingen, en een enkele synology NAS valt daar niet onder.

Beter zoek je het in goede back-ups of replica's. Bijna alle hypervisors ondersteunen tegenwoordig live migratie op local storage)

[Verwijderd]

DukeBox schreef op dinsdag 6 februari 2018 @ 14:21:
[...]

Dat is geen probleem, ik heb heel was syno's met vphere draaien, zolang je het op een rustig IO moment doet kan je gewoon herstarten.

[...]

Nee, een syno in HA doet een failover, de units staan active/passive. De 4 paden blijven 4 paden alleen naar de andere synology welke online komt met dezelfde IP's.

Als dat robuust genoeg is voor TS. Er kan ook iets stukgaan onder hoge load.

[...]

Dat kan wel degelijk maar de initiator moet uiteraard wel clustering ondersteunen. Anders gaat dat met NFS en andere oplossingen ook niet werken. Debian ondersteund (net als alle andere *nix varianten) ook gewoon shared storage met iSCSI. NFS ondersteund tegenwoordig ook MP maar zover ik weet doet syno dat nog niet. Daarnaast mis je dan veel offload/acceleration opties.

Dan beperk je jezelf wel tot cluster-aware filesystem zoals VMFS, Oracle RAC, Gluster, CSVFS.... en de besturingssystemen die een specifiek FS ondersteunen. Met gewoon ext of NTFS gaat dit niet.

[DennusB]

DukeBox schreef op dinsdag 6 februari 2018 @ 14:40:
@DennusB Het default filesystem wordt al niet ondersteund van debian voor live migratie/copy, dan moet je al weer naar riser o.i.d. kijken wat weer vanuit debian niet (meer) ondersteund is. Het is gewoon geen fijne oplossing als je in de problemen raakt. KVM is dan een veel betere keuze en bied eigenlijk dezelfde mogelijkheden.

Domweg alleen op block niveau een kopie maken is gewoon gokken met je data.

Zie https://docs.microsoft.co...rtual-machines-on-hyper-v

Oke, dat Debian niet lekker supported is als guest... maar replicatie heeft niets te maken met het guest OS :

https://docs.microsoft.co...ge/set-up-hyper-v-replica

[DukeBox]

Verwijderd schreef op dinsdag 6 februari 2018 @ 14:49:
Als dat robuust genoeg is voor TS. Er kan ook iets stukgaan onder hoge load.

Het iSCSI protocol (net als normaal SCSI overigens) vereist dat het systeem enige onderbreking moet kunnen opvangen.

Dan beperk je jezelf wel tot cluster-aware filesystem zoals VMFS, Oracle RAC, Gluster, CSVFS.... en de besturingssystemen die een specifiek FS ondersteunen. Met gewoon ext of NTFS gaat dit niet.

Nee, het gaat hier om Debian, zie TS.

[ Voor 29% gewijzigd door DukeBox op 06-02-2018 15:59 ]

[Verwijderd]

DukeBox schreef op dinsdag 6 februari 2018 @ 15:58:
[...]

Het iSCSI protocol (net als normaal SCSI overigens) vereist dat het systeem enige onderbreking moet kunnen opvangen.

[...]

Nee, het gaat hier om Debian, zie TS.

En Ubuntu, en wie weet wat nog meer in de toekomst. Maar als je heel graag een Synology cluster in wil zetten: het schijnt ook gewoon NFS te doen. Ik zie gewoon niet echt voordelen in iSCSI voor de TS.

[DukeBox]

Verwijderd schreef op woensdag 7 februari 2018 @ 06:46:
Ik zie gewoon niet echt voordelen in iSCSI voor de TS.

NFS op synology ondersteund geen MP. Dus geen HA en ook bepeekte bandbreedte.

[Verwijderd]

DukeBox schreef op woensdag 7 februari 2018 @ 07:52:
[...]

NFS op synology ondersteund geen MP. Dus geen HA en ook bepeekte bandbreedte.

Dan blijf ik bij mijn eerste standpunt: niet echt geschikt voor de TS. NFS multipathing is ook niet echt spannend. NFS gaat over TCP/IP, dus in principe is het voldoende om de interface van je NFS server HA te hebben. NFS is een vrij vergevingsgezind protocol, wat prima overweg kan met een server interface die in het geval van een failover ineens op een andere tysieke interface zit. Sessie blijven gewoon leven. Moet je met SMB niet proberen, die sessies verbreken en moeten opnieuw opgezet worden.

Multipathing komt eigenlijk pas in beeld bij NFS 4.1 m.b.v. session trunking. Leuk, maar niet direct noodzakelijk.

[ Voor 50% gewijzigd door Verwijderd op 07-02-2018 08:07 ]

[Hero of Time]

Multipath is niet zo boeiend, gewoon een floating IP gebruiken en de slave deze laten overnemen als de master uitvalt.
En iSCSI klinkt leuk, maar hoe ga je dat fatsoenlijk doen met je file systems als je deze op meer dan 1 machine wilt kunnen gebruiken? Om corruptie te voorkomen en file locking fatsoenlijk te laten werken, zal je met een clustered file system moeten werken. Domweg ext4 of xfs erop zetten is gewoon vragen om problemen.

[DukeBox]

Verwijderd schreef op woensdag 7 februari 2018 @ 08:01:
Dan blijf ik bij mijn eerste standpunt: niet echt geschikt voor de TS.

Waarom dan niet ?

NFS is een vrij vergevingsgezind protocol, wat prima overweg kan met een server interface die in het geval van een failover ineens op een andere tysieke interface zit. Sessie blijven gewoon leven

Dat heeft niets met NFS te maken maar zoals je zelf ook al een beetje aangeeft gewoon met TCP/IP.

Moet je met SMB niet proberen, die sessies verbreken en moeten opnieuw opgezet worden.

Dat heeft met de beveiliging te maken, niet met SMB zelf. Gelukkig is dat met SMB 3 niet meer het geval én nog mooier ondersteund SMB4.1 multipath volledig automagisch. Niet dat dat SMB meteen geschikt maakt voor shared storage want daar komt nog heel wat meer bij kijken.

Multipathing komt eigenlijk pas in beeld bij NFS 4.1 m.b.v. session trunking. Leuk, maar niet direct noodzakelijk.

Jij gaat alleen in op het HA deel van MP, maar júíst een van de voordelen is de schaling. Een path er bij en je verdubbeld je bandbreedte (uitgaande van balanced verbindingen) met daarbij dus ook je max IO's.

[rippiedoos]

En ProxMox met CEPH dan? Dan heb je shared storage zonder daadwerkelijke shared storage. Zit je ook niet te klieren iscsi of NFS met of zonder HA want je storagelaag zelf is dan HA. En de VM’s kunnen dan met ‘gewone’ local storage werken. Enig nadeel is is dat je tenminste 3 proxmox-nodes nodig hebt.

[ Voor 10% gewijzigd door rippiedoos op 15-02-2018 05:13 ]