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

\"Admin
\n\"Admin
\n
\nDetta \u00e4r en myt, ganska utbredd inom serverhardware. I praktiken beh\u00f6vs hyperkonvergerande l\u00f6sningar (n\u00e4r allt finns i ett) f\u00f6r m\u00e5nga olika \u00e4ndam\u00e5l. Historiskt sett s\u00e5 utvecklades de f\u00f6rsta arkitekturerna av Amazon och Google f\u00f6r sina tj\u00e4nster. Id\u00e9n var d\u00e5 att skapa en ber\u00e4kningsfarm best\u00e5ende av identiska noder, d\u00e4r var och en har sina egna diskar. Allt detta kopplades samman av n\u00e5gon form av systemorienterad mjukvara (hypervisor) och delades sedan upp i virtuella maskiner. Huvudsyftet var att minimera anstr\u00e4ngningen f\u00f6r att underh\u00e5lla en nod och minimera problem vid skalning: man k\u00f6pte helt enkelt ytterligare tusen av liknande servrar och kopplade dem bredvid. I praktiken handlar det om enskilda fall, och oftare r\u00f6r det sig om ett mindre antal noder och en n\u00e5got annorlunda arkitektur. <\/p>\n

Men f\u00f6rdelen f\u00f6rblir densamma \u2013 otrolig enkelhet i skalning och hantering. Nackdelen \u2013 olika uppgifter konsumerar resurser p\u00e5 olika s\u00e4tt, och p\u00e5 vissa st\u00e4llen kommer det att finnas gott om lokala diskar, medan andra har f\u00f6r lite RAM och s\u00e5 vidare, vilket inneb\u00e4r att resursutnyttjandet kommer att falla vid olika typer av uppgifter. <\/p>\n

Det visade sig att man betalar 10\u201315 % mer f\u00f6r bekv\u00e4mligheten med konfigurationen. Detta skapade myten i rubriken. Vi letade l\u00e4nge efter var teknologin skulle till\u00e4mpas optimalt, och vi fann det. Faktum \u00e4r att Cisco inte hade sina egna lagringssystem, men de ville ha hela servermarknaden. Och de skapade Cisco Hyperflex \u2013 en l\u00f6sning med lokala lagringssystem p\u00e5 noder. <\/p>\n

Och pl\u00f6tsligt blev detta en mycket bra l\u00f6sning f\u00f6r backupdatacenter (Disaster Recovery). Varf\u00f6r och hur \u2013 det ber\u00e4ttar jag nu. Och jag kommer att visa tester av klustret. <\/a><\/noindex><\/p>\n

D\u00e4r det beh\u00f6vs<\/h3>\n

\nHyperkonvergens \u00e4r: <\/p>\n

    \n
  1. \u00d6verflyttning av diskar till ber\u00e4kningsnoder.<\/li>\n
  2. Fullst\u00e4ndig integration av lagringssystemet med virtualiseringssystemet.<\/li>\n
  3. \u00d6verf\u00f6ring\/integration med n\u00e4tverksystemet.<\/li>\n<\/ol>\n

    \nDenna koppling m\u00f6jligg\u00f6r implementering av m\u00e5nga funktioner i lagringssystem p\u00e5 virtualiseringsniv\u00e5 och allt fr\u00e5n ett och samma hanteringsf\u00f6nster.<\/p>\n

    I v\u00e5rt f\u00f6retag \u00e4r projekt f\u00f6r design av backupdatacenter mycket efterfr\u00e5gade, och man v\u00e4ljer ofta just hyperkonvergerande l\u00f6sningar p\u00e5 grund av sina m\u00e5nga replikationsalternativ (\u00e4nda till metrokluster) direkt ur l\u00e5dan. <\/p>\n

    N\u00e4r det g\u00e4ller backup-datacenter handlar det vanligtvis om en avl\u00e4gsen plats i en annan del av staden eller till och med i en annan stad. Det till\u00e5ter \u00e5terst\u00e4llning av kritiska system vid delvis eller total nedg\u00e5ng av det prim\u00e4ra datacentret. Data fr\u00e5n f\u00f6rs\u00e4ljningen replikeras st\u00e4ndigt dit, och denna replikering kan ske antingen p\u00e5 applikationsniv\u00e5 eller p\u00e5 blocklagringsenhetsniv\u00e5 (SAN).<\/p>\n

    D\u00e4rf\u00f6r kommer jag nu att ber\u00e4tta om systemets struktur och tester, och sedan om n\u00e5gra scenarier f\u00f6r verklig till\u00e4mpning med data om besparingar. <\/p>\n

    Tester<\/h3>\n

    \nV\u00e5r instans best\u00e5r av fyra servrar, d\u00e4r varje server har 10 SSD-diskar p\u00e5 960 GB. Det finns en dedikerad disk f\u00f6r cachning av skrivoperationer och lagring av en service virtuell maskin. Sj\u00e4lva l\u00f6sningen \u00e4r den fj\u00e4rde versionen. Den f\u00f6rsta var uppenbarligen ganska bristf\u00e4llig (enligt recensionerna), den andra var ocks\u00e5 lite bristf\u00e4llig, den tredje \u00e4r redan tillr\u00e4ckligt stabil, och denna kan kallas en release efter att beta-testningen avslutats offentligt. Under testningen s\u00e5g jag inga problem, allt fungerar som en klocka.<\/p>\n

    \u00c4ndringar i v4<\/b>En m\u00e4ngd buggar har fixats. <\/p>\n

    Ursprungligen kunde plattformen endast arbeta med hypervisorn VMware ESXi och st\u00f6dde ett begr\u00e4nsat antal noder. Dessutom avslutades inte alltid distributionsprocessen framg\u00e5ngsrikt, vissa steg fick startas om, det fanns problem med att uppdatera fr\u00e5n \u00e4ldre versioner och datan i GUI visades inte alltid korrekt (\u00e4ven om jag fortfarande inte \u00e4r imponerad av hur prestandadiagrammen visas), ibland uppstod problem i samband med virtualisering.<\/p>\n

    Nu \u00e4r alla barnsjukdomar \u00e5tg\u00e4rdade, HyperFlex kan hantera b\u00e5de ESXi och Hyper-V, plus att det \u00e4r m\u00f6jligt att:<\/p>\n

      \n
    1. Skapa ett distribuerat kluster. <\/li>\n
    2. Skapa ett kontor-kluster utan att anv\u00e4nda Fabric Interconnect, fr\u00e5n tv\u00e5 till fyra noder (vi k\u00f6per bara servrar).<\/li>\n
    3. M\u00f6jlighet att arbeta med externa SAN.<\/li>\n
    4. St\u00f6d f\u00f6r containrar och Kubernetes.<\/li>\n
    5. Skapa tillg\u00e4nglighetszoner.<\/li>\n
    6. Integration med VMware SRM, om den inbyggda funktionen inte \u00e4r tillfredsst\u00e4llande.<\/li>\n<\/ol>\n

      Arkitekturen skiljer sig inte mycket fr\u00e5n konkurrenternas l\u00f6sningar, s\u00e5 vi skapade inte n\u00e5got nytt. Allt k\u00f6rs p\u00e5 virtualiseringsplattformen VMware eller Hyper-V. Det \u00e4r fysiskt placerat p\u00e5 servrar av egen design, Cisco UCS. Det finns de som hatar plattformen p\u00e5 grund av den relativt komplexa initiala konfigurationen, m\u00e5nga knappar, en icke-trivial system av mallar och beroenden, men det finns ocks\u00e5 de som har upplevt zen, f\u00f6rst\u00e5tt konceptet och inte l\u00e4ngre vill arbeta med andra servrar. <\/p>\n

      Vi kommer att titta p\u00e5 l\u00f6sningen f\u00f6r VMware, eftersom den ursprungligen skapades f\u00f6r detta och har mer funktionalitet. Hyper-V har utvecklats under v\u00e4gen f\u00f6r att inte halka efter konkurrenterna och f\u00f6r att motsvara marknadens f\u00f6rv\u00e4ntningar.<\/p>\n

      Det finns en kluster av servrar fyllda med diskar. Det finns diskar f\u00f6r datalagring (SSD eller HDD - efter eget val och behov), och en SSD-disk f\u00f6r cachning. Vid skrivning av data p\u00e5 datalagringen sker lagring av data p\u00e5 cachningslagret (dedikerad SSD-disk och RAM fr\u00e5n service-VM). Samtidigt skickas en datablokk till noderna i klustret (antalet noder beror p\u00e5 faktorn f\u00f6r klustrets replikering). Efter bekr\u00e4ftelse fr\u00e5n alla noder om framg\u00e5ngsrik skrivning skickas bekr\u00e4ftelsen till hypervisorn och vidare till VM. Skrivna data dedupliceras, komprimeras och lagras p\u00e5 lagringsdiskar i bakgrunden. Under detta skrivs alltid ett stort block p\u00e5 lagringsdiskarna sekventiellt, vilket minskar belastningen p\u00e5 lagringsdiskarna.<\/p>\n

      Deduplicering och komprimering \u00e4r st\u00e4ndigt aktiverat och kan inte st\u00e4ngas av. L\u00e4sning av data sker direkt fr\u00e5n lagringsdiskarna eller fr\u00e5n RAM-cache. Om en hybridkonfiguration anv\u00e4nds cachas \u00e4ven l\u00e4sning p\u00e5 SSD-disk.<\/p>\n

      Data \u00e4r inte bundna till den aktuella platsen f\u00f6r den virtuella maskinen och f\u00f6rdelas j\u00e4mnt mellan noderna. Denna metod g\u00f6r det m\u00f6jligt att belasta alla diskar och n\u00e4tverksgr\u00e4nssnitt lika. Det finns en uppenbar nackdel: vi kan inte maximalt minska l\u00e4sf\u00f6rdr\u00f6jningen, eftersom det inte finns n\u00e5gon garanti f\u00f6r att data finns lokalt. Men jag anser att detta \u00e4r en obetydlig uppoffring j\u00e4mf\u00f6rt med de f\u00f6rdelar vi f\u00e5r. Dessutom har n\u00e4tverksf\u00f6rdr\u00f6jningar n\u00e5tt s\u00e5dana niv\u00e5er att de n\u00e4stan inte p\u00e5verkar det slutgiltiga resultatet.<\/p>\n

      En specialiserad tj\u00e4nste-VM, Cisco HyperFlex Data Platform-kontrollern, ansvarar f\u00f6r hela logiken i diskresursens arbete och skapas p\u00e5 varje lagringsnod. I v\u00e5r konfiguration tilldelades tj\u00e4nste-VM \u00e5tta vCPU och 72 GB RAM, vilket inte \u00e4r s\u00e5 lite. Jag p\u00e5minner om att v\u00e4rden sj\u00e4lv har 28 fysiska k\u00e4rnor och 512 GB RAM.<\/p>\n

      Tj\u00e4nste-VM har direkt \u00e5tkomst till de fysiska diskarna genom att passera SAS-kontroller till VM:en. Kommunikation med hypervisorn sker via en specialmodul, IOVisor, som f\u00e5ngar in- och utdataoperationer, och en agent som g\u00f6r det m\u00f6jligt att skicka kommandon till hypervisorns API. Agenten hanterar arbete med HyperFlex-snapshots och kloner.<\/p>\n

      I hypervisorn monteras diskresurser som NFS- eller SMB-delar (beroende p\u00e5 hypervisorns typ; gissa vilken som \u00e4r vilken). Under huven finns ett distribuerat filsystem som m\u00f6jligg\u00f6r till\u00e4gg av funktioner som vuxna, fullfj\u00e4drade lagringssystem: finjustering av volymer, komprimering och deduplicering, snapshots med Redirect-on-Write-teknik samt synkron och asynkron replikering.<\/p>\n

      Tj\u00e4nste-VM ger \u00e5tkomst till webbgr\u00e4nssnittet f\u00f6r hantering av HyperFlex-systemet. Det finns integration med vCenter, och de flesta rutinuppgifter kan utf\u00f6ras d\u00e4rifr\u00e5n, men datastores \u00e4r l\u00e4ttare att sk\u00e4ra fr\u00e5n ett separat webbl\u00e4ge om du redan har \u00f6verg\u00e5tt till den snabba HTML5-gr\u00e4nssnittet, eller anv\u00e4nda den fullst\u00e4ndiga Flash-klienten med full integration. I det tj\u00e4nste-webbl\u00e4get kan du se systemets prestanda och detaljerad status.<\/p>\n

      \"Admin
      \n
      \nDet finns en annan typ av noder i klustret - ber\u00e4kningsnoder. Dessa kan vara rack- eller bladservrar utan inbyggda diskar. P\u00e5 dessa servrar kan VM k\u00f6ras vars data lagras p\u00e5 servrar med diskar. Ur datatillg\u00e5ngens perspektiv finns det ingen skillnad mellan nodtyperna, eftersom arkitekturen f\u00f6ruts\u00e4tter en abstrahering fr\u00e5n datans fysiska placering. Det maximala f\u00f6rh\u00e5llandet mellan ber\u00e4knings- och lagringsnoder \u00e4r 2:1.<\/p>\n

      Anv\u00e4ndningen av ber\u00e4kningsnoder \u00f6kar flexibiliteten vid skalning av klustrets resurser: vi beh\u00f6ver inte n\u00f6dv\u00e4ndigtvis k\u00f6pa noder med diskar om vi bara har behov av CPU\/RAM. Dessutom kan vi l\u00e4gga till en bladkorg och f\u00e5 besparingar p\u00e5 serverplacering i sk\u00e5pet.<\/p>\n

      Som resultat har vi en hyperkonvergerad plattform med f\u00f6ljande funktioner:<\/p>\n