{"id":38966,"date":"2019-10-31T22:27:03","date_gmt":"2019-10-31T19:27:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/admin-bez-ruk-giperkonvergentsiya\/"},"modified":"2019-10-31T22:27:03","modified_gmt":"2019-10-31T19:27:03","slug":"admin-bez-ruk-giperkonvergentsiya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/admin-bez-ruk-giperkonvergentsiya","title":{"rendered":"Admin uten hender = hyperkonvergens?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Admin
\n\"Admin
\n
\nDette er en myte, som er ganske utbredt innen servermaskinvare. I praksis er imidlertid hyperkonvergerte l\u00f8sninger (hvor alt er samlet) n\u00f8dvendige for mange form\u00e5l. Historisk sett ble de f\u00f8rste arkitekturene utviklet av Amazon og Google for sine tjenester. Ideen den gang var \u00e5 bygge en databehandlingsg\u00e5rd av identiske noder, der hver node har sine egne disker. Alt dette ble samlet av en slags systembyggende programvare (hypervisor) og delt opp i virtuelle maskiner. Hovedoppgaven er \u00e5 minimere innsatsen for \u00e5 vedlikeholde en node og minimere problemer ved skalering: man bare kj\u00f8per et par tusen av slike servere til og kobler de sammen. I praksis er dette unntaksvis, og oftere dreier det seg om et mindre antall noder og en litt annen arkitektur. <\/p>\n

Men fordelen forblir den samme \u2013 utrolig enkel skalering og administrasjon. Ulempen er at forskjellige oppgaver bruker ressurser ulikt, hvor noen steder vil det v\u00e6re mange lokale disker, mens der det er lite RAM osv., det vil si at ved forskjellige typer oppgaver vil ressursutnyttelsen falle. <\/p>\n

Det endte med at du betaler 10\u201315 % mer for enkeltheten ved oppsettet. Dette skapte myten fra overskriften. Vi lette lenge etter hvor teknologien ville bli optimalt anvendt, og vi fant det. Saken er at Cisco ikke hadde sine egne lagringssystemer, men de \u00f8nsket \u00e5 ta hele servermarkedet. Og de laget Cisco Hyperflex \u2013 en l\u00f8sning med lokale lagringssystemer p\u00e5 nodene. <\/p>\n

Og plutselig ble dette en veldig god l\u00f8sning for backup datasentre (Disaster Recovery). Hvorfor og hvordan \u2013 skal jeg n\u00e5 fortelle. Og jeg vil vise testene av klyngen. <\/a><\/noindex><\/p>\n

Hvor det trengs<\/h3>\n

\nHyperkonvergens er: <\/p>\n

    \n
  1. Overf\u00f8ring av disker til behandlingsnoder.<\/li>\n
  2. Full integrasjon av datalagringssystemet med virtualiseringssystemet.<\/li>\n
  3. Overf\u00f8ring\/integrering med nettverksystemet.<\/li>\n<\/ol>\n

    \nSlik en kopling gj\u00f8r det mulig \u00e5 implementere mange funksjoner i lagringssystemer p\u00e5 virtualiseringsniv\u00e5 og alt fra ett administrasjonsvindu.<\/p>\n

    I v\u00e5rt selskap er prosjekter for design av backup datasentre veldig ettertraktet, og det velges ofte nettopp en hyperkonvergent l\u00f8sning p\u00e5 grunn av mange alternativer for replikering (helt opp til metrokluster) fra boksen. <\/p>\n

    I tilfeller med backup datacenters handler det vanligvis om en fjernplassering p\u00e5 den andre siden av byen eller til og med i en annen by. Dette tillater gjenoppretting av kritiske systemer i tilfelle delvis eller fullstendig svikt av hoved datacentret. Dataene fra produksjonen replikeres kontinuerlig dit, og denne replikeringen kan skje p\u00e5 applikasjonsniv\u00e5 eller p\u00e5 niv\u00e5et med lagringsenheter (SAN).<\/p>\n

    Derfor vil jeg n\u00e5 fortelle om systemets oppbygging og tester, og deretter om et par scenarier for virkelig bruk med data om besparelser. <\/p>\n

    Tester<\/h3>\n

    \nV\u00e5r instans best\u00e5r av fire servere, hvor hver har 10 SSD-er p\u00e5 960 GB. Det er en dedikert disk for hurtigbufring av skriveoperasjoner og lagring av en tjeneste virtuell maskin. Selve l\u00f8sningen er den fjerde versjonen. Den f\u00f8rste var \u00e5penbart uferdig (if\u00f8lge tilbakemeldingene), den andre var ogs\u00e5 noe ustabil, den tredje var allerede ganske stabil, og denne kan kalles en utgivelse etter avslutningen av beta-testing for publikum. I l\u00f8pet av testingen har jeg ikke sett noen problemer, alt fungerer som det skal.<\/p>\n

    Endringer i v4<\/b>En haug med feil er rettet. <\/p>\n

    Opprinnelig kunne plattformen bare arbeide med hypervisoren VMware ESXi og st\u00f8ttet et begrenset antall noder. I tillegg ble ikke distribusjonsprosessen alltid vellykket, og noen trinn m\u00e5tte startes p\u00e5 nytt, det var problemer med oppdatering fra eldre versjoner, og dataene i GUI ble ikke alltid vist korrekt (selv om jeg fortsatt ikke er begeistret for visningen av ytelsesgrafer), av og til oppstod det problemer med virtualisering.<\/p>\n

    N\u00e5 er alle barndomsfeil rettet, HyperFlex fungerer med b\u00e5de ESXi og Hyper-V, pluss at det er mulig:<\/p>\n

      \n
    1. Opprettelse av et utvidet kluster. <\/li>\n
    2. Opprettelse av et kluster for kontorer uten bruk av Fabric Interconnect, fra to til fire noder (vi kj\u00f8per bare serverne).<\/li>\n
    3. Mulighet for \u00e5 arbeide med eksterne SAN-er.<\/li>\n
    4. St\u00f8tte for containere og Kubernetes.<\/li>\n
    5. Oppretting av tilgjengelighetssoner.<\/li>\n
    6. Integrasjon med VMware SRM, hvis den innebygde funksjonaliteten ikke er tilfredsstillende.<\/li>\n<\/ol>\n

      Arkitekturen avviker ikke mye fra l\u00f8sningene til de viktigste konkurrentene, de har ikke laget et nytt konsept. Alt dette fungerer p\u00e5 virtualiseringsplattformer som VMware eller Hyper-V. Maskinvaren er plassert p\u00e5 servere utviklet av Cisco UCS. Det finnes de som hater plattformen p\u00e5 grunn av den relative kompleksiteten ved opprinnelig oppsett, mange knapper, en komplisert mal- og avhengighetssystem, men det er ogs\u00e5 de som har opplevd zen, har tatt ideen til seg og ikke \u00f8nsker \u00e5 jobbe med andre servere lenger. <\/p>\n

      Vi vil spesifikt se p\u00e5 l\u00f8sningen for VMware, da l\u00f8sningen opprinnelig ble utviklet for denne plattformen og har st\u00f8rre funksjonalitet. Hyper-V ble forbedret underveis, for ikke \u00e5 komme bak konkurrentene og for \u00e5 m\u00f8te markedets forventninger.<\/p>\n

      Det finnes en klynge av servere fylt med disker. Det er disker for datalagring (SSD eller HDD \u2014 avhengig av din smak og behov), samt en SSD-disk for hurtigbuffer. N\u00e5r data skrives til datalageret, lagres dataene i hurtigbufferlaget (den dedikerte SSD-disk og RAM av det tjeneste-VMer). Samtidig sendes en datablokk til nodene i klyngen (antallet noder avhenger av replikasjonsfaktoren i klyngen). Etter bekreftelse fra alle noder om vellykket skriving, sendes bekreftelsen tilbake til hypervisoren og videre til VM. De lagrede dataene dedupliseres, komprimeres og skrives til lagringsdiskene i bakgrunnen. Under dette skrives det alltid en stor blokk til lagringsdiskene og sekvensielt, noe som reduserer belastningen p\u00e5 lagringsdisken.<\/p>\n

      Deduplication og komprimering er alltid aktivert, og de kan ikke sl\u00e5s av. Data leses direkte fra lagringsdiskene eller fra RAM-cachen. Hvis en hybridkonfigurasjon brukes, caches lesing ogs\u00e5 p\u00e5 SSD-disk.<\/p>\n

      Dataene er ikke bundet til den n\u00e5v\u00e6rende plasseringen av den virtuelle maskinen og fordeles jevnt mellom nodene. Denne tiln\u00e6rmingen gj\u00f8r det mulig \u00e5 belaste alle disker og nettverksgrensesnitt likt. Det \u00e5penbare negative punktet er at vi ikke kan maksimalt redusere lesetiden, siden det ikke er noen garanti for at dataene er lokalt tilgjengelige. Men jeg mener at dette er en ubetydelig pris \u00e5 betale i forhold til de oppn\u00e5dde fordelene. I tillegg har nettverksforsinkelsene n\u00e5dd niv\u00e5er som praktisk talt ikke p\u00e5virker det samlede resultatet.<\/p>\n

      Hele logikken i diskunder-systemet styres av en spesialtjeneste VM, Cisco HyperFlex Data Platform controller, som opprettes p\u00e5 hver lagringsnode. I v\u00e5r konfigurasjon ble det tildelt \u00e5tte vCPU og 72 GB RAM til tjeneste-VM-en, noe som ikke er s\u00e5 lite. Husk at selve verten har 28 fysiske kjerner og 512 GB RAM.<\/p>\n

      Tjeneste-VM-en har direkte tilgang til de fysiske diskene ved hjelp av SAS-kontrolleren som videresendes til VM-en. Kommunikasjonen med hypervisoren skjer gjennom en spesialmodul, IOVisor, som fanger opp I\/O-operasjoner, og ved hjelp av en agent som gj\u00f8r det mulig \u00e5 sende kommandoer til hypervisorens API. Agenten har ansvar for h\u00e5ndtering av HyperFlex-snapshots og kloner.<\/p>\n

      I hypervisoren monteres diskressursene som en NFS- eller SMB-deling (avhengig av typen hypervisor, gjett hvilken hvor). Og under panseret er det et distribuert filsystem som lar deg legge til funksjoner fra fullverdige SAN-er: tynn tildeling av volumer, komprimering og deduplisering, snapshots med Redirect-on-Write teknologi, synkron og asynkron replikering.<\/p>\n

      Tjeneste-VM-en gir tilgang til nettgrensesnittet for administrasjon av HyperFlex-systemet. Det finnes integrasjon med vCenter, og de fleste daglige oppgavene kan utf\u00f8res fra dette, men datalagringsomr\u00e5der er for eksempel lettere \u00e5 opprette fra et separat webgrensesnitt, spesielt hvis du allerede har g\u00e5tt over til det hurtige HTML5-grensesnittet, eller bruke en fullverdig Flash-klient med full integrasjon. I tjeneste-nettgrensesnittet kan du se ytelsen og detaljerte systemstatus.<\/p>\n

      \"Admin
      \n
      \nDet finnes ogs\u00e5 en annen type noder i klyngen \u2014 beregningsnoder. Dette kan v\u00e6re rack- eller blade-servere uten innebygde disker. P\u00e5 disse serverne kan du kj\u00f8re VM-er hvis dataene lagres p\u00e5 servere med disker. I forhold til datatilgang er det ingen forskjell mellom nodetypene, siden arkitekturen forutsetter abstraksjon fra den fysiske plasseringen av dataene. Det maksimale forholdet mellom beregningsnoder og lagringsnoder er 2:1.<\/p>\n

      Bruken av beregningsnoder \u00f8ker fleksibiliteten ved skalering av klusterressurser: vi trenger ikke n\u00f8dvendigvis \u00e5 kj\u00f8pe noder med disker hvis vi bare har behov for CPU\/RAM. I tillegg kan vi legge til en blade-kasse og oppn\u00e5 besparelse ved plassering av servere i rack.<\/p>\n

      Som et resultat har vi en hyperkonvergert plattform med f\u00f8lgende funksjoner:<\/p>\n