{"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\/da\/blog\/administrirovanie\/admin-bez-ruk-giperkonvergentsiya","title":{"rendered":"Admin uden h\u00e6nder = hyperkonvergens?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Admin
\n\"Admin
\n
\nDette er en myte, der er ret udbredt inden for serverhardware. I praksis er hyperkonvergerende l\u00f8sninger (hvor alt er samlet i \u00e9n) n\u00f8dvendige til mange form\u00e5l. Historisk set blev de f\u00f8rste arkitekturer udviklet af Amazon og Google til deres tjenester. Ideen dengang var at lave en beregningsfarmen af ensartede noder, hvor hver enkelt havde sine egne diske. Alt dette blev samlet af en form for systemdannende software (hypervisor) og opdelt i virtuelle maskiner. Hovedopgaven var minimum indsats til vedligeholdelse af en node og minimum problemer ved skalering: man kunne simpelthen k\u00f8be endnu et tusinde eller to af de samme servere og tilslutte dem ved siden af. I praksis er dette dog enest\u00e5ende tilf\u00e6lde, og langt oftere handler det om f\u00e6rre noder og en lidt anden arkitektur. <\/p>\n

Men fordelen forbliver den samme - utrolig enkelhed i skalering og administration. Ulempen er, at forskellige opgaver forbruger ressourcer forskelligt, og der vil v\u00e6re mange lokale diske et sted, men lidt RAM et andet sted, og s\u00e5 videre, hvilket betyder, at udnyttelsen af ressourcerne vil falde med forskellige typer opgaver. <\/p>\n

Det endte med, at du betalte 10\u201315% mere for bekvemmeligheden ved ops\u00e6tningen. Det er det, der skabte myten fra overskriften. Vi har l\u00e6nge ledt efter, hvor teknologien ville blive anvendt optimalt, og vi fandt det. Faktisk havde Cisco ikke deres egne SAN-l\u00f8sninger, men de \u00f8nskede hele servermarkedet. Og de lavede Cisco Hyperflex - en l\u00f8sning med lokale lagre p\u00e5 noderne. <\/p>\n

Og pludselig viste det sig at v\u00e6re en meget god l\u00f8sning til backup datacentre (Disaster Recovery). Hvorfor og hvordan - det vil jeg nu fort\u00e6lle. Og jeg vil vise cluster-tests. <\/a><\/noindex><\/p>\n

Hvor det er n\u00f8dvendigt<\/h3>\n

\nHyperkonvergens er: <\/p>\n

    \n
  1. Flytning af diske til beregningsnoder.<\/li>\n
  2. Fuldst\u00e6ndig integration af lagringssystemet med virtualiseringssystemet.<\/li>\n
  3. Flytning\/integration med netv\u00e6rkssystemet.<\/li>\n<\/ol>\n

    \nDenne kombination muligg\u00f8r realisering af mange funktioner ved SAN-niveauet i virtualiseringen, alt sammen fra \u00e9n administrationsgr\u00e6nseflade.<\/p>\n

    I vores virksomhed er projekter til design af backup datacentre meget eftertragtede, og der v\u00e6lges ofte netop hyperkonvergerende l\u00f8sninger p\u00e5 grund af de mange muligheder for replikation (helt ned til metrokluster) lige ud af boksen. <\/p>\n

    I tilf\u00e6lde af backup datacentre taler man normalt om en fjernlokation, der ligger p\u00e5 den anden side af byen eller endda i en anden by. Det g\u00f8r det muligt at gendanne kritiske systemer i tilf\u00e6lde af delvis eller total svigt af det prim\u00e6re datacenter. Data fra produktionen replikeres konstant til dette sted, og denne replikering kan finde sted p\u00e5 applikationsniveau eller p\u00e5 blokniveau (Lagringssystem).<\/p>\n

    Derfor vil jeg nu fort\u00e6lle om systemets opbygning og tests, og derefter om et par scenarier for praktisk anvendelse med data om omkostningsbesparelser. <\/p>\n

    Tests<\/h3>\n

    \nVores implementering best\u00e5r af fire servere, hver med 10 SSD-diske p\u00e5 960 GB. Der er en dedikeret disk til caching af skriveoperationer og opbevaring af en service virtuel maskine. Selve l\u00f8sningen er i fjerde version. Den f\u00f8rste var \u00e5benlyst ustabil (if\u00f8lge anmeldelser), den anden var stadig lidt r\u00e5, den tredje er allerede ret stabil, og denne kan betragtes som en udgivelse efter afslutningen af beta-testning p\u00e5 et bredere publikum. I l\u00f8bet af testningen har jeg ikke oplevet problemer, alt fungerer som en dr\u00f8m.<\/p>\n

    \u00c6ndringer i v4<\/b>En masse fejl er blevet rettet. <\/p>\n

    Oprindeligt kunne platformen kun arbejde med hypervisoren VMware ESXi og underst\u00f8ttede et lille antal noder. Udrulningsprocessen var heller ikke altid vellykket og kr\u00e6vede nogle gange genstart af flere trin, der var problemer med opdatering fra gamle versioner, og data i GUI'en blev ikke altid vist korrekt (selvom jeg stadig ikke er begejstret for visningen af pr\u00e6stationsgrafer), nogle gange opstod der problemer i relation til virtualisering.<\/p>\n

    Nu er alle b\u00f8rnesygdomme blevet rettet, HyperFlex underst\u00f8tter b\u00e5de ESXi og Hyper-V, plus muligheden for:<\/p>\n

      \n
    1. Oprettelse af et udvidet cluster. <\/li>\n
    2. Oprettelse af et cluster til kontorer uden brug af Fabric Interconnect, fra to til fire noder (vi k\u00f8ber kun serverne).<\/li>\n
    3. Mulighed for at arbejde med eksterne lagringssystemer.<\/li>\n
    4. Underst\u00f8ttelse af containere og Kubernetes.<\/li>\n
    5. Oprettelse af tilg\u00e6ngelighedszoner.<\/li>\n
    6. Integration med VMware SRM, hvis den indbyggede funktionalitet ikke er tilfredsstillende.<\/li>\n<\/ol>\n

      Arkitekturen adskiller sig ikke v\u00e6sentligt fra l\u00f8sningerne fra de store konkurrenter, og vi har ikke genopfundet hjulet. Alt dette k\u00f8rer p\u00e5 virtualiseringsplatformen VMware eller Hyper-V. Det er hardwarem\u00e6ssigt placeret p\u00e5 servere, der er udviklet af Cisco UCS. Der er dem, der hader platformen p\u00e5 grund af den relativt komplekse indledende ops\u00e6tning, de mange knapper, det ikke-trivielle skabelonsystem og afh\u00e6ngigheder, men der er ogs\u00e5 dem, der har opn\u00e5et zen, har taget ideen til sig og ikke l\u00e6ngere \u00f8nsker at arbejde med andre servere. <\/p>\n

      Vi vil fokusere p\u00e5 l\u00f8sningen til VMware, da l\u00f8sningen oprindeligt blev udviklet til dette og har en st\u00f8rre funktionalitet, mens Hyper-V er blevet tilpasset undervejs for at indhente konkurrenterne og im\u00f8dekomme markedets forventninger.<\/p>\n

      Der er et cluster af servere, som er fyldt med diske. Der er diske til datalagring (SSD eller HDD \u2014 efter dit valg og behov), og der er \u00e9n SSD-disk til caching. N\u00e5r data skrives til datastoret, gemmes dataene p\u00e5 cache-laget (den dedikerede SSD-disk og RAM i service-VM'en). Samtidig sendes datablokken til noderne i clusteret (antallet af noder afh\u00e6nger af replikationsfaktor for clusteret). Efter bekr\u00e6ftelse fra alle noder om succesfuld skrivning sendes bekr\u00e6ftelse af skrivningen til hypervisoren og videre til VM'en. De skrevne data dedupliceres, komprimeres og skrives til lagerdiske i baggrunden. I denne proces skrives der altid store blokke til lagerdiskene i r\u00e6kkef\u00f8lge, hvilket reducerer belastningen p\u00e5 lagerdiskene.<\/p>\n

      Deduplication og kompression er konstant aktiveret og kan ikke deaktiveres. L\u00e6sning af data sker direkte fra lagerdiskene eller fra RAM-cachen. Hvis der benyttes en hybridkonfiguration, caches l\u00e6sningen ogs\u00e5 p\u00e5 SSD-disken.<\/p>\n

      Dataene er ikke knyttet til den nuv\u00e6rende placering af den virtuelle maskine og fordeles j\u00e6vnt mellem noderne. Denne tilgang g\u00f8r det muligt at belastning af alle diske og netv\u00e6rksgr\u00e6nseflader ensartet. En \u00e5benlys ulempe opst\u00e5r: vi kan ikke maksimalt reducere l\u00e6sningslatenstiden, da der ikke er nogen garanti for, at dataene er tilg\u00e6ngelige lokalt. Men jeg mener, at det er en ubetydelig pris at betale i forhold til de opn\u00e5ede fordele. Desuden er latenstiderne i netv\u00e6rket n\u00e5et til niveauer, som n\u00e6sten ikke p\u00e5virker det samlede resultat.<\/p>\n

      Hele logikken for diskunderst\u00f8ttelsen varetages af en speciel service-VM, Cisco HyperFlex Data Platform controller, som oprettes p\u00e5 hver lagringsnode. I vores konfiguration blev der tildelt otte vCPU og 72 GB RAM til service-VM'en, hvilket ikke er s\u00e5 lidt. Husk, at selve v\u00e6rtsystemet har 28 fysiske kerner og 512 GB RAM.<\/p>\n

      Service-VM'en har direkte adgang til de fysiske diske ved hj\u00e6lp af SAS-controller bypass i VM'en. Kommunikation med hypervisoren foreg\u00e5r gennem en speciel IOVisor-modul, som opsnapper input-output-operationer, og via en agent, der muligg\u00f8r kommandooverf\u00f8rsel til hypervisorens API. Agenten er ansvarlig for arbejde med HyperFlex-snapshots og kloner.<\/p>\n

      I hypervisoren monteres diskressourcer som NFS- eller SMB-deling (afh\u00e6ngigt af typen af hypervisor, g\u00e6t hvilken der er hvilken). Under motorhjelmen er det et distribueret filsystem, der muligg\u00f8r tilf\u00f8jelse af funktioner til mere avancerede SAN-l\u00f8sninger: fin tildeling af volumener, komprimering og deduplisering, snapshots ved hj\u00e6lp af Redirect-on-Write teknologi, synkron\/ asynkron replikation.<\/p>\n

      Service-VM'en giver adgang til WEB-gr\u00e6nsefladen for styring af HyperFlex-underst\u00f8ttelsen. Der er integration med vCenter, og de fleste daglige opgaver kan udf\u00f8res derfra, men datalagre er for eksempel lettere at opdele fra en s\u00e6rskilt webgr\u00e6nseflade, hvis du allerede er skiftet til det hurtige HTML5-interface, eller du kan bruge en fuld Flash-klient med komplet integration. I service-webgr\u00e6nsefladen kan du se systemets ydeevne og detaljeret status.<\/p>\n

      \"Admin
      \n
      \nDer findes ogs\u00e5 en anden type node i klyngen - compute nodes. Dette kan v\u00e6re rack- eller blade-servere uden indbyggede diske. P\u00e5 disse servere kan der k\u00f8res VM'er, hvis data opbevares p\u00e5 servere med diske. Fra et datatilgangsperspektiv er der ingen forskel mellem nodetyperne, da arkitekturen foruds\u00e6tter abstraktion fra den fysiske placering af dataene. Det maksimale forhold mellem compute nodes og storage nodes er 2:1.<\/p>\n

      Brugen af compute nodes \u00f8ger fleksibiliteten ved skalering af klyngens ressourcer: Vi beh\u00f8ver ikke n\u00f8dvendigvis at k\u00f8be noder med diske, hvis vi kun har behov for CPU\/RAM. Desuden kan vi tilf\u00f8je en blade-skuffe og opn\u00e5 besparelser ved placering af servere i rack.<\/p>\n

      Som resultat har vi en hyperkonvergeret platform med f\u00f8lgende funktioner:<\/p>\n