HPe Smart Cache - mix van SSD en HDD (MongoDB OPS cluster)

[j-a-s-p-e-r]

Beste PNSers,

Ik zit met een issue in de opzet een een mongoDB Ops manager cluster. Dit cluster is een management/schaduw/backup cluster van een productiecluster bestaande uit 3 nodes. De hardware waar ik nu aan zit te denken is bijv een HPe DL380 Gen 9 of Gen10, 64GB, E5-2530v4 met ~64GB.

De netto opslag capaciteit moet ongeveer 10TB per server zijn. (direct attached). In de toekomst liefst schaalbaar/uitbreidbaar.

Mijn eerste opzet was met een aantal SAS disks in RAID 10, helaas is dit volgens MongoDB zelf niet afdoende. Hoeveel performance exact nodig is weet ik niet want dit cluster is nieuw voor ons (ik kan alleen maar requirements verzinnen obv een Percona XtraDB (mysql) cluster, maar dat zegt hier niet zoveel nuttigs over). Ik wil echter het dringende advies van MongoDB zelf niet in de wind slaan en zoek nu een oplossing die ons niet financieel te kop kost. Aangezien het OPS cluster een schaduw cluster is van productie (voor backups/management) moet deze ook min of meer even snel mee kunnen schrijven op inserts.

Drie oplossingen die ik tot nu toe heb bedacht:

• Gebruik van HP Smartcache op de controller en mix van SSD en HDD.
• HPe overboord zetten en voor een merk gaan waar ik non-genuine disks in kan gebruiken, bijv. 2x

• Downsizing van de requirements (minder backups) en bijv. een 7.82TB NVME PCIe kaart erin hangen en proberen de storage te verdelen over die kaart + extra disks. Dit is de grootste prutsoplossing

Mijn voorkeur gaat uit naar HP SmartCache, alleen is hier weinig over te vinden en hebben (drie) leveranciers hier ook niet echt veel aan toe toe te voegen behalve 'ja wel een goed idee'. Heeft iemand van jullie ervaring hiermee? Is dit ook voor schrijf-toepassingen sneller dan bijv. SAS disks, of is dat ijdele hoop?

Of heeft iemand anders een ander goed idee voor mij? Ik zit een beetje vast helaas.

[Equator]

Die smartcache feature lijkt wel interressant.

Ik lees:

quote: https://www.hpe.com/us/en...ontroller.1010026917.html

Accelerate access to data in HDD environments by caching hot data onto SSDs with HPE Smart Array SR SmartCache (included feature).

Maar er staat niet hoe de verdeling is. Moet je dan 1 SSD per SAS RAID, of maak je een SSD RAID welke je gebruikt met alle SAS RAIDs.

Ik begrijp dat je bare metal wilt gaan? Anders zou je met een hypervisor en Software Defined Storage een flexibelere oplossing kunnen maken. Een DL380 SFF24 kan je 4 diskgroepen geven met 5xSAS+1xSSD op vSAN. Maar dat vereist dat je meerdere van dergelijke systemen moet hebben draaien. EN of dat dan de juiste capaciteit en performance gaat geven.. Je bent in ieder geval niet gebonden aan deze specifieke server, makkelijk met HW onderhoud. Maar de kosten gaan wel x3

Maar kan je niet iemand bij HPE zelf bereiken die je hiermee kan helpen?

Edit: leesvoer: https://www.hpe.com/us/en.../detail/pip.5364342.html#

[ Voor 4% gewijzigd door Equator op 17-11-2017 14:11 ]

[j-a-s-p-e-r]

Ja mij lijkt ie ook mega interessant, maar lees/hoor weinig over praktische ervaring ermee. Komt het in de buurt van een SSD qua IOPS of is het een leuke gimmick. En dan nog read vs write, ook lastig om te vergelijken. Linkje had ik gezien, ook behoorlijk wat gezocht ook youtube (wat een slechte filmpjes van HP staan daar zeg). Hetgeen nog het meeste in de buurt kwam is volledig in het Russisch (YouTube: 26/02/2015 – Вебинар....

De setup wordt idd bare metal, dat bevalt mij bij deze size van DBs (2TB+) wel het beste. Alleen jammer dat ik aan servers ca 60K kwijt ben en losse SSDs erbij nog zo'n 70K extra, dat wordt voor ons als niet heel groot bedrijf iets te gek.

Ik zal idd eens proberen om iemand van HPe zelf te pakken te krijgen. Dat ik daar nog niet aan gedacht heb haha.

[Zoetjuh]

Het zou mij niets verbazen wanneer dit op de zelfde manier werkt als de NetApp oplossing.

SSD's worden ingezet om 'hot' data (lees: data blocks die veel worden gelezen) op SSD de cachen.
Deze 'hot' blocks kunnen vervolgens vanuit de SSD gelezen worden ipv je normale HDD's.

Writes gebeuren nog altijd naar de cache van de controller, welke de data weer naar disk flushed.

Er is dus geen a:b verhouding of iets. Je read-SSD-cache size is dus bapaald door hoeveel SSD's je inzet voor deze read-cache oplossing (en houd daarbij rekening met eventuele RAID-levels op je SSD cache disks).

[Rolfie]

Ik heb de smartcache optie voor een Exchange 2013 oplossing besteld, voornamelijk omdat ik bang was dat de sata disks niet voldoende lees I/O konden aanbieden.

Hij staat als het goed is nu geconfigureerd als read cache icm de SSDs en de cache van raid controller is de write cache. Dit voldoet voldoende voor ons. Al zou ik wel weer eens kunnen kijken, hoeveel cache hit dit nu werkelijk oplevert. Ik heb helaas geen performance testen met en zonder kunnen doen. Tijd was daar toen niet voor.

Volgens mij kan je het zowel voor read als schrijf write cache instellen, al moet je dan we mirrors maken voor de write cache. Als je wilt kan ik nog wel eens in de GUI kijken op de servers.
Ik heb nog waarschijnlijk wel wat PDF's liggen die interessant waren om te lezen, ze kwamen wel van de HP website. Ik kan deze nog wel eens opzoeken voor je als je wilt.

[j-a-s-p-e-r]

@Zoetjuh . Ja idd, lijkt er sterk op. Heb zelf even overwogen om helemaal de IBM kant op te gaan, maar die zijn volgens mij nog een stukje duurder zelf dan HP.

Hi @Rolfie , Fijn eindelijk wat praktijk ervaring. Bij mij zou het idd om write caching gaan.
Mocht je die PDF's nog ergens hebben zou je ze dan willen mailen? Zou echt super zijn Email is mijn nick zonder streepjes @ algra.io

Inmiddels via HPe zelf ook op zoek, maar eerste spoor liep dood in 'uh ik denk je bij ons geen SSD en HDD kan mixen'. Grappenmakers. Nu HPe NL maar daar heb ik ook niet erg veel hoop in.

[Equator]

Volgende week zit ik bij HPE Discover in Madrid, zal daar ook eens rondkijken. Want ik vind het wel een interessante feature

[Question Mark]

Nadeel van dit soort cache oplossing is dat je ontzettend goed moet weten wat de verhouding tussen "hot-data" en normale data is. Vaak wordt als vuistregel minimaal 10% gehanteerd, maar dat kan in de praktijk sterk afwijken.

Stel dat deze oplossing (met SSD caching) op bedrag X uitkomt. Kijk dan ook even hoeveel traditionele SAS-spindels je voor dat geld kunt krijgen. Meer spindels is meer IOPS, en daar profiteert dan alle data van.

[Dennism]

Question Mark schreef op maandag 20 november 2017 @ 11:43:
Nadeel van dit soort cache oplossing is dat je ontzettend goed moet weten wat de verhouding tussen "hot-data" en normale data is. Vaak wordt als vuistregel minimaal 10% gehanteerd, maar dat kan in de praktijk sterk afwijken.

Stel dat deze oplossing (met SSD caching) op bedrag X uitkomt. Kijk dan ook even hoeveel traditionele SAS-spindels je voor dat geld kunt krijgen. Meer spindels is meer IOPS, en daar profiteert dan alle data van.

Punt is wel dat voordat je zover spindels kan krijgen om gelijk te komen met de cache implementaties je toch echt wel een stuk verder bent.

Maar sizing van je cache is inderdaad belangrijk.

@j-a-s-p-e-r Ik vind trouwens de prijzen die je noemt wel vrij hoog. Bij een fatoenlijke HPE partner hoeven 3x een DL380G9 met 64GB ram en een E5-2630v4 echt geen 60K te kosten, 20k tot misschien 25k per server, dat lijken mij eerder prijzen voor die specs met 6 tot 10TB flash erin

[Question Mark]

Dennism schreef op maandag 20 november 2017 @ 13:03:
[...]
@j-a-s-p-e-r Ik vind trouwens de prijzen die je noemt wel vrij hoog. Bij een fatoenlijke HPE partner hoeven 3x een DL380G9 met 64GB ram en een E5-2630v4 echt geen 60K te kosten, 20k tot misschien 25k per server, dat lijken mij eerder prijzen voor die specs met 6 tot 10TB flash erin

Ik heb wel eens SAN's opgeleverd op basis van een CTO DL380 (Configure to Order). Daar zaten uit mijn hoofd 12 disken in. Die zaten rond de 9K per stuk.. En dat was met 2GB cache op de raidcontroller en veel redudantie opties.

[Dennism]

Question Mark schreef op maandag 20 november 2017 @ 13:06:
[...]

Ik heb wel eens SAN's opgeleverd op basis van een CTO DL380 (Configure to Order). Daar zaten uit mijn hoofd 12 disken in. Die zaten rond de 9K per stuk.. En dat was met 2GB cache op de raidcontroller en veel redudantie opties.

Maar die waren niet all flash denk ik dan? Want zou dan wel weer heel goedkoop zijn. Als ik zo even snel kijk zit een DL380Gen9 met 2 voedingen, een 2630v4 cpu en 64 GB ram en standaard controller zo'n 5k zonder kortingen, dit is echter wel het 8 of 10 disk chassis. Maak daar een 24 disk chassis van, 2de CPU en misschien een wat duurdere storage controller en dat moet met standaard kortingen door een beetje HP partner wel te leveren zijn voor 6-7k, hebben ze nog 13K over om er 10TB flash in te gooien, aangezien ze zelf lopen te roepen dat Enterprise grade Flash momenteel minder dan een dollar per GB hoeft te kosten moet dat ook makkelijk kunnen

[jimbo123]

Maaruh, heb je ook al eens een HPE MSA overwogen met Performance Tiering?

[Question Mark]

Dennism schreef op maandag 20 november 2017 @ 13:13:
[...]


Maar die waren niet all flash denk ik dan?

Nope, zonder Flash...

[j-a-s-p-e-r]

@Dennism 50~60K is 6x server (3x productiecluster + 3x ops manager). Productie heeft 4TB flash, OPS 12TB SAS. Dan kloppen de prijzen wel weer toch?

@jimbo123 Het gaat om losse servers in HA cluster met storage in de server zelf. Een SAN zou kunnen maar dan moet die ook HA zijn en bovendien geschikt voor 3 drukke grote databases. Die SAN gaan bouwen zie ik niet zoo veel heil in, zal ook niet snel goedkopere optie worden.

@Question Mark Jouw optie (meer spindels) ga ik ook zeker bekijken.

[Question Mark]

Dennism schreef op maandag 20 november 2017 @ 13:03:
[...]


Punt is wel dat voordat je zover spindels kan krijgen om gelijk te komen met de cache implementaties je toch echt wel een stuk verder bent.

Het is maar net de vraag of je dit nodig bent. Je komt qua performance een heel eind met 4GB FBWC op je Raidcontroller(s)..

[squaddie]

Vooropgesteld ik ben met name een storage admin en kom uiteraard wel in aanraking met databases, maar minder diepgaande sql kennis.

Om bij je vraag te beginnen, in het verleden hebben we voor een klant ook gekeken naar Smart cache alleen konden we toen geen enkele praktijkervaring ermee vinden en zowel HP als de leverancier niet wilde meewerken aan het leveren van een demo systeem leveren ten behoeve van performance tests. Omdat we praktisch geen praktijk informatie hadden hebben we de klant geadviseerd een Compellent met combinatie van SSDs en 10k disks en deze sas gekoppeld aan de server. Blijkbaar is de situatie weinig veranderd want er is nog weinig praktijk ervaringen te vinden.

Persoonlijk vindt ik het lastig om alternatieve oplossingen aan te dragen, er zijn nog een hoop variabelen die niet ingevuld zijn, maar wel veel invloed uitoefenen op de te kiezen oplossing.

Aangezien MongoDB een negatief oordeel heeft gegeven op de voorgestelde configuratie dan ga ik er vanuit dat ze wel een indicatie hebben van hoeveel IOs nodig zijn en de verhouding lees/schrijf acties. Is er een idee hoe groot de actieve dataset gaat zijn?

Laten we als voorbeeld nemen dat een server 1000 IOs moet verwerken, mijn vuistregel is disk rpm gedeeld door 100 voor reguliere disks, als dit met 7.2k disks wil doen heb je 14 disks nodig, echter je wilt ook redundancy en kom je bij raid 10 op 28 disks in totaal uit. Zelfde rekensom met 10k disks kom je op 20 disks uit. Nogmaals ik heb geen idee of aansluit bij jouw situatie, wellicht dat het een handvat bied.

Overigens hoeft het niet-productie cluster niet perse dezelfde hardware te hebben. Als een productie server 1000 IOs met read/write verhouding van 50 procent doet, heeft de niet-productie server aan 500 IOs voldoende immers deze server krijgt niet de reads die productie server wel krijgt. Tenzij de niet-productie server in geval nood de rol van productie server moet kunnen overnemen.

[j-a-s-p-e-r]

Hi @squaddie
Die vuistregel van jou is interessant! Grappig dat ik niet de enige ben die weinig kan vinden op het hele smart cache gebeuren. Ik zit echt bijna te overwegen om HPe de deur uit te zetten, zo'n afknapper dit.

Ik ben nu twee wegen aan het bewandelen:

Bij HPe NL heb ik gister ongeveer 1,5 uur aan de telefoon gehangen om net zo vaak doorverbonden te worden. Uiteindelijk een sales director zijn 06 gekregen die het ook niet wist (uiteraard) maar wel iemand heeft opgedragen om mij vandaag antwoord te geven.. ik ben benieuwd. Alleen het feit dat er zo weinig over bekend is maakt mij ook huiverig om hiermee een beetje te gaan pionieren in iets dat heel snel productie moet worden.. Mocht ik wat horen dan post ik het hier uiteraard ook.

Optie twee is toch een split in storage van de database server, dus het gros op de HDD en de kleinere 'opslog' en applicatie databases op SSD. Het lastige hieraan is dat per server 3 databases nodes worden gerund voor de verschillende functies. En dat nog op twee andere servers ook. Maar als het toch blijkt te kunnen dan is dit wellicht de beste optie. Dan kan ik met een twee flinke SSDs in raid 1 van circa 4TB per server ook wel uit de voeten.

[thijszor]

Onderstaande in je zoektocht al tegengekomen @j-a-s-p-e-r ?

https://www.lanclan.nl/wp...014/06/hp_smart_cache.pdf
https://habrahabr.ru/company/hpe/blog/277285/

Vrees dat je inderdaad echt geluk moet hebben dat je bij een persoon terecht komt (binnen HPE) die er een project mee gedaan heeft, user case(s) kan delen, etc. etc.

[ Voor 15% gewijzigd door thijszor op 21-11-2017 14:53 ]

[SpamLame]

Van HPe zelf.
De mogelijkheid om een smartcache eval license te krijgen (moet je wel de gear ervoor hebben, maar wellicht kan je een demo box krijgen voor tests)
https://h20392.www2.hpe.c...uctNumber=SMARTCACHE-EVAL

En de quickspecs https://www.hpe.com/h2019...nt.aspx?docname=c04123148

Zoals ik het lees zijn de (smart) cache volumes inzetbaar als read only of RW* (waarbij data later destaged wordt naar HDDs.).
*Afhankelijk van Generatie en type controller.

Wat het beste voor jou usecase is zal je (het liefst) moeten testen met je eigen data aan de hand van door jou opgestelde eisen.

Als je schaalbaarheid/uitbreidbaarheid (wbt diskslots) wilt dan lijkt een DL380 24+X SFF chassis de betere keuze.
Denk je dat dat onvoldoende is gedurende de afschrijftermijn en vind je JBOD enclosures als bv een D3700 geen probleem overweeg dan een SAS controller (erbij) te nemen die (ook) externe poorten aanbied voor makkelijker aansluiten van toekomstige uitbreidingen.

Wbt partners/resellers: Ik heb veel HPe aankopen via MCL.de laten lopen, in mijn ogen een goede toko met schappelijke prijzen en service.

Mijn achtergrond: HPe gebruiker van G3 t/m Gen9 servers (300+) met mixed inzet van full flash SSD achter SA controllers, Workload Accelerators (vroegere Fusion-IO), tientallen MSA2040 met SSD readcache, Compellent Automated Tiering arrays

[Rolfie]

@j-a-s-p-e-r Ik zet ze even hier neer. Zodat iedereen ze kan lezen.

HP SmartCache technology
Optimized solid-state drive performance with HP SSD Smart Path

When using the HP SmartCache solution for direct-attached storage, legacy cache is still present and operational; it utilizes the remaining space in the FBWC memory. When using HP SmartCache, the Smart Array DDR cache will be set to 100 percent write operation which enables write-back functionality in DDR cache. This allows SSDs configured as HP SmartCache volumes to provide a much larger read cache.

Since the HP SmartCache solution is implemented within the Smart Array firmware, it can be used on any operating system supported by HP ProLiant servers. The HP SmartCache solution operates transparently, with no dependencies on operating system, device driver software, file system type, or applications.
HP SmartCache supports write-through caching. When an application writes data to the disk, the Smart Array Controller writes the data to the HDDs; if the data is also in the cache volume, the data is written to the SSD.

Dit is eigenlijk het belangrijkste stukje tekst.

Je gebruikt dus voornamelijk de SSD als lees cache, en de standaard onboard FBWC als schrijf cache.

[Question Mark]

squaddie schreef op maandag 20 november 2017 @ 21:50:
mijn vuistregel is disk rpm gedeeld door 100 voor reguliere disks.

Dat geldt niet altijd, er moet wel rekening gehouden worden met de formfactor van de disken. De seektimes op een 2,5" SFF disk zijn veel lager dan de seektimes op een 3,5" LFF disk. Dat zie je dan ook terugkomen in IOPS.

Nu maakt dat voor een DL380 niet uit, die is (exotische configs buiten beschouwing gelaten) alleen maar met SFF disks uit te rusten.

Daarnaast houdt je in je berekening géén rekening met caching op de Raid controller. Dat kan veel impact hebben op de (piek)performance.

[squaddie]

Klopt helemaal dat formfactor invloed heeft op de seektimes en daarmee op het aantal IOPS. Mijn vuistregel is in het algemeen lager dan wat de disks daadwerkelijk doen, maar voor een rekensom op een bierviltje goed genoeg of iemand op weg te helpen met storage sizing.

Ik neem praktisch nooit de controller en het cache mee in de berekening omdat ik persoonlijk het lastig vindt de effectiviteit van de controller te meten zeker bij bijvoorbeeld virtualisatie. Ander punt is BBU-batterij als deze defect gaat schakelt de controller over op "veilige modus" (write through en write cache uit) heb ik de voorkeur om niet helemaal te vertrouwen op write back en write cache.