{"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\/et\/blog\/administrirovanie\/admin-bez-ruk-giperkonvergentsiya","title":{"rendered":"Admin ilma k\u00e4ed = h\u00fcperkonvergents?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Admin
\n\"Admin
\n
\nSee on m\u00fc\u00fct, mis on serveritehnika valdkonnas suhteliselt levinud. Praktiliselt on h\u00fcperkonvergeeritud lahendused (kui k\u00f5ik on \u00fches) vajalikud paljuski. Ajalooliselt on esimesed arhitektuurid v\u00e4lja t\u00f6\u00f6tanud Amazon ja Google oma teenuste jaoks. Siis oli m\u00f5te luua arvutifarmer \u00fchetaolistest s\u00f5lmedest, millest iga\u00fchel on oma kettad. K\u00f5ik see \u00fchendati mingi s\u00fcsteemitekitava tarkvaraga (h\u00fcperviisor) ja jagati seej\u00e4rel virtuaalsete masinate vahel. Peamine \u00fclesanne \u2014 minimaalne vaeva \u00fche s\u00f5lme hooldamiseks ja minimaalne probleemide arv skaleerimisel: lihtsalt osteti veel tuhat-kaks sellist serverit ja \u00fchendati ritta. Praktiliselt on need \u00fcksikud juhud, ja palju sagedamini r\u00e4\u00e4gitakse v\u00e4iksemast s\u00f5lmede arvust ja pisut teisest arhitektuurist. <\/p>\n

Kuid pluss j\u00e4\u00e4b samaks \u2014 uskumatult lihtne skaleerimine ja haldamine. Miinus \u2014 erinevad \u00fclesanded tarbivad ressursse erinevalt, ja kuskile on palju kohalikke kettaid, kuskile v\u00e4he RAM-i ja nii edasi, st erinevat t\u00fc\u00fcpi \u00fclesannete korral langeb ressursi kasutus. <\/p>\n

Selgus, et maksate 10\u201315% rohkem mugavuse seadistamise eest. Just see t\u00f5i kaasa siin nimetatud m\u00fc\u00fcdi. Otsisime pikka aega, kus saaks tehnoloogiat optimaalselt rakendada, ja leidsime. Asi on selles, et Ciscol ei olnud oma andmesalvestuss\u00fcsteeme, kuid nad soovisid t\u00e4ielikku serveriturgu. Ja nad tegid Cisco Hyperflex \u2014 lahendus kohalike salvestustega s\u00f5lmedel. <\/p>\n

Ja sellest tulenevalt sai v\u00e4ga hea lahenduse \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u044b\u0445 \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u043e\u0432 (Disaster Recovery). Miks ja kuidas \u2014 r\u00e4\u00e4gin n\u00fc\u00fcd. Ja n\u00e4itan klastrite teste. <\/a><\/noindex><\/p>\n

Kus on vajalik<\/h3>\n

\nH\u00fcperkonvergeeritus \u2014 see on: <\/p>\n

    \n
  1. Kettade viimine arvutis\u00f5lmedesse.<\/li>\n
  2. T\u00e4pne integratsioon andmesalvestuse alamprogrammi ja virtualiseerimise alamprogrammi vahel.<\/li>\n
  3. Viimine\/integratsioon v\u00f5rgu alamprogrammi.<\/li>\n<\/ol>\n

    \nSelline paar v\u00f5imaldab rakendada paljusid andmesalvestuse funktsioone virtualiseerimise tasandil ja k\u00f5ik \u00fchest haldusaknast.<\/p>\n

    Meie ettev\u00f5ttes on v\u00e4ga n\u00f5utud projektid reservdata keskustest ja sageli valitakse just h\u00fcperkonvergeeritud lahendus t\u00e4nu kohutavalt paljudele replikatsiooni v\u00f5imalustele (kuni metroklaster) kastist v\u00e4lja. <\/p>\n

    Varuv\u00e4ravakeskuste puhul r\u00e4\u00e4gitakse tavaliselt kaugobjektist, mis asub linnas v\u00f5i isegi teises linnas. See v\u00f5imaldab taastada kriitilised s\u00fcsteemid p\u00f5hiv\u00e4ravakeskuse osalise v\u00f5i t\u00e4ieliku rikke korral. Andmed replikeeritakse pidevalt m\u00fc\u00fcgiserverist, ja see replikatsioon v\u00f5ib toimuda rakenduse tasemel v\u00f5i plokkseadmestiku tasemel (SAN).<\/p>\n

    Seet\u00f5ttu r\u00e4\u00e4gin n\u00fc\u00fcd s\u00fcsteemi struktuurist ja testidest, ja seej\u00e4rel \u2014 paarist tegeliku rakenduse stsenaariumist koos kokkuhoidu puudutavate andmetega. <\/p>\n

    Testid<\/h3>\n

    \nMeie mudel koosneb neljast serverist, milles on iga\u00fches 10 SSD-diski, mille suurus on 960 GB. On eraldatud ketas kirjutamise ja teenindava virtuaalmasina operatsioonide vahem\u00e4luks. Lahendus ise on neljas versioon. Esimene oli avatud toode (kohtuotsuste alusel), teine oli samuti ebastabiilne, kolmas oli juba piisavalt stabiilne, ja seda saab nimetada v\u00e4ljalaskeversiooniks p\u00e4rast avaliku beetatesti l\u00f5ppu. Testimise ajal ei m\u00e4rganud ma probleeme, k\u00f5ik t\u00f6\u00f6tab nagu kell.<\/p>\n

    Muutused v4-s<\/b>Palju vigu on parandatud. <\/p>\n

    Alguses suutis platvorm t\u00f6\u00f6tada ainult h\u00fcpervisoriga VMware ESXi ja toetas v\u00e4ikest arvu node. Samuti ei l\u00f5ppenud juurutamisprotsess kaugeltki alati edukalt, m\u00f5ningaid etappe tuli taas k\u00e4ivitada, esines probleeme vanematelt versioonidelt uuendamisel, andmeid GUI-s ei kuvatud alati \u00f5igesti (kuigi ma ei ole praegugi graafikute kuvamise osas k\u00fcll rahul), m\u00f5nikord esines probleeme virtualiseerimisega.<\/p>\n

    Praegu on k\u00f5ik lastehaigused parandatud, HyperFlex toetab nii ESXi-d kui ka Hyper-V-d, lisaks on v\u00f5imalik:<\/p>\n

      \n
    1. Laiendatud klastri loomine. <\/li>\n
    2. Klastri loomine kontorite jaoks ilma Fabric Interconnecti kasutamiseta, kahe kuni nelja nodega (ostame ainult serverid).<\/li>\n
    3. V\u00f5ime t\u00f6\u00f6tada v\u00e4liste SAN-idega.<\/li>\n
    4. Konteinerite ja Kubernetes'e tugi.<\/li>\n
    5. Saadavuspiirkondade loomine.<\/li>\n
    6. Integreerimine VMware SRM-iga, kui sisseehitatud funktsioon ei rahulda.<\/li>\n<\/ol>\n

      Arhitektuur ei erine oluliselt peamistest konkurentidest, uut ratast pole loodud. See t\u00f6\u00f6tab virtuelleerimise platvormil VMware v\u00f5i Hyper-V. F\u00fc\u00fcsiliselt on see paigutatud Cisco UCSi enda v\u00e4ljat\u00f6\u00f6tatud serveritesse. On inimesi, kes vihkavad platvormi selle suhtelise keerukuse, rohkete nuppude, keerulise mallide ja s\u00f5ltuvuste s\u00fcsteemi t\u00f5ttu, kuid leidub ka neid, kes on saavutanud zen'i, on ideest haaranud ja ei soovi enam teiste serveritega t\u00f6\u00f6tada. <\/p>\n

      K\u00e4sitleme just VMware lahendust, kuna see lahendus loodi algselt selle jaoks ja omab suuremat funktsionaalsust; Hyper-V-d on hiljem t\u00e4iustatud, et mitte konkurentidest maha j\u00e4\u00e4da ja turu ootustele vastata.<\/p>\n

      On olemas klaster serveritest, mis on t\u00e4idetud ketastega. Andmete salvestamiseks on ketas (SSD v\u00f5i HDD \u2014 teie valik ja vajadused), seal on \u00fcks SSD-ketas vahem\u00e4llu salvestamiseks. Andmete kirjutamisel andmestoori salvestatakse andmed vahem\u00e4lu kihile (p\u00fchendatud SSD-ketas ja RAM teenindus-VM). Samal ajal saadetakse andmepakk s\u00f5lmedesse klastri sees (s\u00f5lmede arv s\u00f5ltub klastri replikatsiooni tegurist). P\u00e4rast k\u00f5igilt s\u00f5lmedelt edu t\u00f5endamist saadetakse kirjutamise kinnitus h\u00fcperviisorile ja seej\u00e4rel \u2014 VM-le. Salvestatud andmeid deduplitseeritakse, tihendatakse ja salvestatakse salvestusketastele taustal. Sel juhul kirjutatakse alati suur plokk salvestusketastele j\u00e4rjestikku, mis v\u00e4hendab nende koormust.<\/p>\n

      Deduplikatsioon ja tihendamine on pidevalt lubatud ja neid ei saa v\u00e4lja l\u00fclitada. Andmete lugemine toimub otse salvestusketastelt v\u00f5i RAM-i vahem\u00e4lu kaudu. Kui kasutatakse h\u00fcbriidkonfiguratsiooni, siis ka lugemine vahem\u00e4lust SSD-ketast.<\/p>\n

      Andmed ei ole seotud virtuaalmasina praeguse asukohaga ja jaotatakse s\u00f5lmede vahel \u00fchtlaselt. Selline l\u00e4henemine v\u00f5imaldab koormata k\u00f5iki kettaid ja v\u00f5rgu liidesi \u00fchtlaselt. T\u00f5ukab selgelt esile miinus: me ei saa lugemise viivitust maksimaalselt v\u00e4hendada, kuna puudub garantii, et andmed asuvad kohalikult. Kuid ma arvan, et see on t\u00fchine ohver saadud plusside v\u00f5rreldes. Eriti kuna v\u00f5rgu viivitused on saavutanud selliseid suurusi, et praktiliselt ei m\u00f5juta \u00fcldist tulemust.<\/p>\n

      Kogu diskialtistiku t\u00f6\u00f6logika eest vastutab spetsiaalne teenus-WM Cisco HyperFlex Data Platform controller, mis luuakse igas salvestusnode'is. Meie konfiguratsioonis on teenus-WM-le eraldatud kaheksa vCPU-d ja 72 GB RAM-i, mis ei ole sugugi v\u00e4he. Tuletan meelde, et hostil on 28 f\u00fc\u00fcsilist s\u00fcdamikku ja 512 GB RAM-i.<\/p>\n

      Teenuse-WM-ile on otse f\u00fc\u00fcsilistele kettale juurdep\u00e4\u00e4s SAS-kontrolleri edastamise kaudu WM-is. Suhtlemine h\u00fcperviisoriga toimub spetsiaalse IOVisor mooduli kaudu, mis p\u00fc\u00fcab kinni sisendi-v\u00e4ljundi toimingud, ja agendi abil, mis v\u00f5imaldab anda k\u00e4ske h\u00fcperviisori API-le. Agent on vastutav HyperFlex-i snapshotide ja kloonide haldamise eest.<\/p>\n

      H\u00fcperviisorisse on diskiresursid monteeritud kui NFS- v\u00f5i SMB-jagamised (s\u00f5ltub h\u00fcperviisori t\u00fc\u00fcbist, proovige \u00e4ra arvata, mis kus). Aga selle all on jaotatud failis\u00fcsteem, mis v\u00f5imaldab lisada t\u00e4iendavaid funktsioone t\u00e4iskasvanute t\u00f5sistele salvestuss\u00fcsteemidele: peene mahu eraldumise, pigistamise ja deduplikatsiooni, Redirect-on-Write tehnoloogia p\u00f5hiseid snapshots, s\u00fcnkroonset\/ as\u00fcnkroonset replikatsiooni.<\/p>\n

      Teenuse-WM pakub juurdep\u00e4\u00e4su HyperFlex s\u00fcsteemi haldamise veebiliidesele. On olemas integreerimine vCenter'iga, ja enamus igap\u00e4evaseid \u00fclesandeid saab sealt t\u00e4ita, kuid datastooride jagamist on mugavam teha eraldi veebiliidesest, kui olete juba kiirele HTML5- liidesele \u00fcle l\u00e4inud, v\u00f5i kasutada t\u00e4ie\u00f5iguslikku Flash-klienti t\u00e4ie integreerimisega. Teenuse veebiliideses on v\u00f5imalik vaadata s\u00fcsteemi j\u00f5udlust ja t\u00e4pset staatust.<\/p>\n

      \"Admin
      \n
      \nKlastris on olemas ka teine t\u00fc\u00fcp node'id - arvutusnode'id. Need v\u00f5ivad olla 19. v\u00f5i blade-serverid ilma sisseehitatud kettaideta. Nendel serveritel saab k\u00e4itada WM-e, mille andmed on salvestatud ketastega serverites. Andmetele juurdep\u00e4\u00e4su osas pole t\u00fc\u00fcpide vahel mingit erinevust, kuna arhitektuur eeldab andmete f\u00fc\u00fcsilisest asukohast abstraktsiooni. Arvutusnode'ide ja salvestusnode'ide maksimaalne suhe on 2:1.<\/p>\n

      Arvutusnode'ide kasutamine suurendab klassiressursside skaleerimise paindlikkust: me ei pea tingimata ostma ketastega node'e, kui meie vajadus on ainult CPU\/RAM. Lisaks saame lisada blade-korvi ja saavutada kokkuhoidu serverite paigutamisel riiulis.<\/p>\n

      Kokkuv\u00f5ttes on meil h\u00fcperkonvergeeritud platvorm j\u00e4rgmiste funktsioonidega:<\/p>\n