{"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\/hu\/blog\/administrirovanie\/admin-bez-ruk-giperkonvergentsiya","title":{"rendered":"Admin k\u00e9z n\u00e9lk\u00fcl = hiperkonvergencia?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Admin
\n\"Admin
\n
\nEz egy m\u00edtosz, amely a szerverhardver ter\u00fclet\u00e9n elterjedt. A gyakorlatban azonban a hiperkonverg\u00e1lt megold\u00e1sok (amikor minden egyben van) sokf\u00e9le c\u00e9lra sz\u00fcks\u00e9gesek. T\u00f6rt\u00e9nelmileg az els\u0151 architekt\u00far\u00e1kat az Amazon \u00e9s a Google fejlesztette ki saj\u00e1t szolg\u00e1ltat\u00e1saik sz\u00e1m\u00e1ra. Akkor a c\u00e9l az volt, hogy egy homog\u00e9n csom\u00f3pontokb\u00f3l \u00e1ll\u00f3 sz\u00e1m\u00edt\u00e1si farmot hozzanak l\u00e9tre, ahol minden egyes csom\u00f3pont saj\u00e1t meghajt\u00f3kkal rendelkezik. Mindez egy rendszeralkot\u00f3 szoftver (hypervisor) seg\u00edts\u00e9g\u00e9vel egyes\u00fclt, \u00e9s virtu\u00e1lis g\u00e9pekre oszlott. A f\u0151 c\u00e9l: a lehet\u0151 legkevesebb er\u0151fesz\u00edt\u00e9s egy csom\u00f3pont karbantart\u00e1s\u00e1ra \u00e9s a probl\u00e9m\u00e1k minimaliz\u00e1l\u00e1sa a sk\u00e1l\u00e1z\u00e1s sor\u00e1n: csak v\u00e1s\u00e1rolni kellett ezer m\u00e1sik hasonl\u00f3 szervert \u00e9s csatlakoztatni mell\u00e9. A gyakorlatban ezek egyedi esetek, \u00e9s sokkal gyakrabban a kevesebb csom\u00f3pont \u00e9s valamivel elt\u00e9r\u0151 architekt\u00fara j\u00f6n sz\u00f3ba. <\/p>\n

De az el\u0151ny tov\u00e1bbra is ugyanaz \u2013 hihetetlen egyszer\u0171s\u00e9g a sk\u00e1l\u00e1z\u00e1sban \u00e9s a kezel\u00e9sben. H\u00e1tr\u00e1ny \u2013 a k\u00fcl\u00f6nb\u00f6z\u0151 feladatok k\u00fcl\u00f6nb\u00f6z\u0151 m\u00e9rt\u00e9kben haszn\u00e1lj\u00e1k az er\u0151forr\u00e1sokat, \u00edgy p\u00e9ld\u00e1ul egyes helyeken sok helyi meghajt\u00f3, m\u00e1sutt pedig kev\u00e9s RAM tal\u00e1lhat\u00f3, teh\u00e1t k\u00fcl\u00f6nb\u00f6z\u0151 feladatt\u00edpusok eset\u00e9n cs\u00f6kken a forr\u00e1sok kihaszn\u00e1lts\u00e1ga. <\/p>\n

\u00cdgy kider\u00fclt, hogy 10-15%-kal t\u00f6bbet fizet az egyszer\u0171 be\u00e1ll\u00edt\u00e1s\u00e9rt. Ez okozta a fenti m\u00edtoszt. Hossz\u00fa ideig kerest\u00fck, hol alkalmazhat\u00f3 optim\u00e1lisan a technol\u00f3gia, \u00e9s megtal\u00e1ltuk. Az a helyzet, hogy a Cisco-nak nem volt saj\u00e1t t\u00e1rol\u00f3rendszere, de meg akarta szerezni a teljes szerverpiacot. \u00cdgy megsz\u00fcletett a Cisco Hyperflex \u2013 egy megold\u00e1s helyi t\u00e1rol\u00f3kkal a csom\u00f3pontokon. <\/p>\n

\u00c9s ebb\u0151l egyszer csak egy nagyon j\u00f3 megold\u00e1s sz\u00fcletett a tartal\u00e9k adatk\u00f6zpontok sz\u00e1m\u00e1ra (Disaster Recovery). Mi\u00e9rt \u00e9s hogyan \u2013 most elmes\u00e9lem. \u00c9s bemutatom a klaszter teszteket. <\/a><\/noindex><\/p>\n

Ahol sz\u00fcks\u00e9g van r\u00e1<\/h3>\n

\nA hiperkonvergencia az: <\/p>\n

    \n
  1. A meghajt\u00f3k \u00e1thelyez\u00e9se a sz\u00e1m\u00edt\u00e1si csom\u00f3pontokba.<\/li>\n
  2. Teljes integr\u00e1ci\u00f3 az adatt\u00e1rol\u00e1si alrendszer \u00e9s a virtualiz\u00e1ci\u00f3s alrendszer k\u00f6z\u00f6tt.<\/li>\n
  3. \u00c1thelyez\u00e9s\/integr\u00e1ci\u00f3 a h\u00e1l\u00f3zati alrendszerrel.<\/li>\n<\/ol>\n

    \nEz a kapcsolat lehet\u0151v\u00e9 teszi sz\u00e1mos t\u00e1rol\u00e1si funkci\u00f3 megval\u00f3s\u00edt\u00e1s\u00e1t a virtualiz\u00e1ci\u00f3 szintj\u00e9n, mindezt egyetlen kezel\u0151fel\u00fcletr\u0151l.<\/p>\n

    C\u00e9g\u00fcnkn\u00e9l nagyon keresettek a tartal\u00e9k adatk\u00f6zpontok tervez\u00e9s\u00e9re ir\u00e1nyul\u00f3 projektek, \u00e9s gyakran v\u00e1lasztanak hiperkonverg\u00e1lt megold\u00e1st a sok replik\u00e1ci\u00f3s lehet\u0151s\u00e9g (a metr\u00f3klasztert\u0151l kezdve) r\u00e9v\u00e9n, amely alap\u00e9rtelmezettk\u00e9nt el\u00e9rhet\u0151. <\/p>\n

    A tartal\u00e9k adatk\u00f6zpontok eset\u00e9ben \u00e1ltal\u00e1ban egy m\u00e1sik v\u00e1rosban l\u00e9v\u0151 t\u00e1voli objektumr\u00f3l van sz\u00f3, amely lehet\u0151v\u00e9 teszi a kritikus rendszerek helyre\u00e1ll\u00edt\u00e1s\u00e1t a f\u0151 adatk\u00f6zpont r\u00e9szleges vagy teljes le\u00e1ll\u00e1sa eset\u00e9n. Az adatok folyamatosan replik\u00e1l\u00f3dnak a termel\u00e9si k\u00f6rnyezetb\u0151l, \u00e9s ez a replik\u00e1ci\u00f3 lehet alkalmaz\u00e1sszint\u0171 vagy blokk eszk\u00f6z szint\u0171 (t\u00e1rol\u00f3rendszer).<\/p>\n

    Ez\u00e9rt most elmondom a rendszer fel\u00e9p\u00edt\u00e9s\u00e9t \u00e9s a teszteket, majd pedig n\u00e9h\u00e1ny val\u00f3s haszn\u00e1lati forgat\u00f3k\u00f6nyvet az megtakar\u00edt\u00e1si adatokkal kapcsolatban. <\/p>\n

    Tesztel\u00e9s<\/h3>\n

    \nA p\u00e9ld\u00e1nyunk n\u00e9gy szerverb\u0151l \u00e1ll, mindegyikben 10 SSD-meghajt\u00f3val, 960 GB kapacit\u00e1ssal. Van egy dedik\u00e1lt meghajt\u00f3 az \u00edr\u00e1si m\u0171veletek gyors\u00edt\u00f3t\u00e1raz\u00e1s\u00e1hoz \u00e9s a szolg\u00e1ltat\u00f3 virtu\u00e1lis g\u00e9p t\u00e1rol\u00e1s\u00e1hoz. Maga a megold\u00e1s a negyedik verzi\u00f3. Az els\u0151 nyilv\u00e1nval\u00f3an gyerekcip\u0151ben j\u00e1rt (a v\u00e9lem\u00e9nyek alapj\u00e1n), a m\u00e1sodik m\u00e9g mindig gyerekes, a harmadik m\u00e1r el\u00e9g stabil, ezt pedig a nyilv\u00e1nos b\u00e9tatesztel\u00e9s befejez\u00e9se ut\u00e1ni kiad\u00e1snak nevezhetj\u00fck. A tesztel\u00e9s sor\u00e1n probl\u00e9m\u00e1t nem tapasztaltam, minden z\u00f6kken\u0151mentesen m\u0171k\u00f6dik.<\/p>\n

    V\u00e1ltoz\u00e1sok a v4-ben<\/b>Sok hiba jav\u00edtva lett. <\/p>\n

    Kezdetben a platform csak a VMware ESXi hiperv\u00edzorral m\u0171k\u00f6d\u00f6tt \u00e9s csak kis sz\u00e1m\u00fa csom\u00f3pontot t\u00e1mogattak. A telep\u00edt\u00e9si folyamat nem mindig z\u00e1rult le sikeresen, bizonyos l\u00e9p\u00e9seket \u00fajra kellett ind\u00edtani, voltak probl\u00e9m\u00e1k a r\u00e9gebbi verzi\u00f3kb\u00f3l val\u00f3 friss\u00edt\u00e9ssel, az adatok nem mindig jelentek meg helyesen a GUI-ban (b\u00e1r most sem vagyok el\u00e9gedett a teljes\u00edtm\u00e9nygrafikonok megjelen\u00edt\u00e9s\u00e9vel), n\u00e9ha probl\u00e9m\u00e1k mer\u00fcltek fel a virtualiz\u00e1ci\u00f3val kapcsolatban.<\/p>\n

    Most minden gyerekbetegs\u00e9get kijav\u00edtottak, a HyperFlex tudja az ESXi-t \u00e9s a Hyper-V-t is, r\u00e1ad\u00e1sul lehets\u00e9ges:<\/p>\n

      \n
    1. Kiterjesztett klaszter l\u00e9trehoz\u00e1sa. <\/li>\n
    2. Irod\u00e1k sz\u00e1m\u00e1ra klaszter l\u00e9trehoz\u00e1sa Fabric Interconnect haszn\u00e1lata n\u00e9lk\u00fcl, k\u00e9t-t\u0151l n\u00e9gy csom\u00f3pontig (csak a szervereket v\u00e1s\u00e1roljuk).<\/li>\n
    3. Lehet\u0151s\u00e9g k\u00fcls\u0151 t\u00e1rol\u00f3rendszerekkel val\u00f3 egy\u00fcttm\u0171k\u00f6d\u00e9sre.<\/li>\n
    4. Kont\u00e9nerek \u00e9s Kubernetes t\u00e1mogat\u00e1sa.<\/li>\n
    5. Hozz\u00e1f\u00e9rhet\u0151s\u00e9gi z\u00f3n\u00e1k l\u00e9trehoz\u00e1sa.<\/li>\n
    6. Integr\u00e1ci\u00f3 a VMware SRM-mel, ha a be\u00e9p\u00edtett funkci\u00f3 nem megfelel\u0151.<\/li>\n<\/ol>\n

      Az architekt\u00fara nem k\u00fcl\u00f6nb\u00f6zik t\u00fals\u00e1gosan a f\u0151 versenyt\u00e1rsak megold\u00e1sait\u00f3l, nem alkottak \u00faj ker\u00e9ket. Az eg\u00e9sz a VMware vagy Hyper-V virtualiz\u00e1ci\u00f3s platformon m\u0171k\u00f6dik. Hardveresen a Cisco UCS saj\u00e1t fejleszt\u00e9s\u0171 szerverein helyezkedik el. Vannak, akik gy\u0171l\u00f6lik a platformot a kezdeti konfigur\u00e1ci\u00f3 viszonylagos bonyolults\u00e1ga, a sok gomb, a nem trivi\u00e1lis sablon- \u00e9s f\u00fcgg\u0151s\u00e9gi rendszer miatt, de vannak olyanok is, akik meg\u00e9rtett\u00e9k a l\u00e9nyeget, \u00e1t\u00e9rezt\u00e9k az \u00f6tletet, \u00e9s m\u00e1r nem akarnak m\u00e1s szerverekkel dolgozni. <\/p>\n

      Kifejezetten a VMware megold\u00e1s\u00e1val foglalkozunk, mivel a megold\u00e1s eredetileg erre lett kifejlesztve, \u00e9s nagyobb funkcionalit\u00e1ssal b\u00edr; a Hyper-V-t menet k\u00f6zben finom\u00edtott\u00e1k, hogy ne maradjon le a versenyt\u00e1rsakt\u00f3l \u00e9s megfeleljen a piaci elv\u00e1r\u00e1soknak.<\/p>\n

      Van egy klaszter\u00fcnk szerverekb\u0151l, amelyek tele vannak meghajt\u00f3kkal. Vannak adatok t\u00e1rol\u00e1s\u00e1ra szolg\u00e1l\u00f3 meghajt\u00f3k (SSD vagy HDD \u2014 az \u00d6n \u00edzl\u00e9se \u00e9s ig\u00e9nyei szerint), \u00e9s egy SSD meghajt\u00f3 a gyors\u00edt\u00e1shoz. Amikor adatokat \u00edrunk a datastore-ba, az adatok a gyors\u00edt\u00f3 r\u00e9tegen (a dedik\u00e1lt SSD meghajt\u00f3 \u00e9s a szolg\u00e1ltat\u00e1s VM RAM-ja) ker\u00fclnek ment\u00e9sre. P\u00e1rhuzamosan egy adatblokk k\u00fcld\u00e9sre ker\u00fcl a klaszter csom\u00f3pontjaira (a csom\u00f3pontok sz\u00e1ma a klaszter replik\u00e1ci\u00f3s t\u00e9nyez\u0151j\u00e9t\u0151l f\u00fcgg). Miut\u00e1n minden csom\u00f3pont meger\u0151s\u00edtette a sikeres \u00edr\u00e1st, a meger\u0151s\u00edt\u00e9s az hypervisorhoz \u00e9s a VM-hez ker\u00fcl. A h\u00e1tt\u00e9rben mentett adatokat deduplik\u00e1lj\u00e1k, t\u00f6m\u00f6r\u00edtik \u00e9s t\u00e1rol\u00e1sra ker\u00fclnek a meghajt\u00f3kra. Ennek sor\u00e1n a t\u00e1rol\u00f3 meghajt\u00f3kra mindig egy nagy blokk\u00e9nt \u00edrj\u00e1k, sorban, ami cs\u00f6kkenti a t\u00e1rol\u00f3 meghajt\u00f3k terhel\u00e9s\u00e9t.<\/p>\n

      A deduplik\u00e1ci\u00f3 \u00e9s a t\u00f6m\u00f6r\u00edt\u00e9s folyamatosan bekapcsolva van, \u00e9s nem lehet kikapcsolni \u0151ket. Az adatok olvas\u00e1sa k\u00f6zvetlen\u00fcl a t\u00e1rol\u00f3 meghajt\u00f3kr\u00f3l vagy a RAM gyors\u00edt\u00f3b\u00f3l t\u00f6rt\u00e9nik. Ha hibrid konfigur\u00e1ci\u00f3t haszn\u00e1lnak, az olvas\u00e1s szint\u00e9n az SSD meghajt\u00f3n van gyors\u00edtva.<\/p>\n

      Az adatok nincsenek r\u00f6gz\u00edtve a virtu\u00e1lis g\u00e9p aktu\u00e1lis hely\u00e9hez, \u00e9s egyenletesen oszlanak el a csom\u00f3pontok k\u00f6z\u00f6tt. Ez a megk\u00f6zel\u00edt\u00e9s lehet\u0151v\u00e9 teszi, hogy az \u00f6sszes meghajt\u00f3t \u00e9s h\u00e1l\u00f3zati interf\u00e9szt egyenletesen terhelj\u00fcnk. Nyilv\u00e1nval\u00f3 h\u00e1tr\u00e1ny, hogy nem tudjuk maxim\u00e1lisan cs\u00f6kkenteni az olvas\u00e1si k\u00e9sleltet\u00e9st, mivel nincs garancia arra, hogy az adatok helyben vannak. De \u00fagy v\u00e9lem, hogy ez elhanyagolhat\u00f3 \u00e1ldozat a nyert el\u0151ny\u00f6kh\u00f6z k\u00e9pest. F\u0151leg, hogy a h\u00e1l\u00f3zati k\u00e9sleltet\u00e9sek olyan \u00e9rt\u00e9keket \u00e9rtek el, hogy szinte nem befoly\u00e1solj\u00e1k az \u00f6sszes\u00edtett eredm\u00e9nyt.<\/p>\n

      A disk subsystem's overall functionality is managed by a dedicated service VM, the Cisco HyperFlex Data Platform controller, which is created on each storage node. In our configuration, the service VM was allocated eight vCPUs and 72 GB of RAM, which is quite substantial. Just to remind you, the host itself has 28 physical cores and 512 GB of RAM.<\/p>\n

      The service VM has direct access to the physical disks through SAS-controller passthrough into the VM. Communication with the hypervisor occurs via a special IOVisor module, which intercepts input-output operations, and through an agent that allows commands to be sent to the hypervisor's API. The agent is responsible for working with HyperFlex snapshots and clones.<\/p>\n

      In the hypervisor, the disk resources are mounted as NFS or SMB shares (depending on the type of hypervisor, guess which is which). Under the hood, it\u2019s a distributed file system that allows adding features of mature full-fledged storage systems: thin provisioning, compression, deduplication, Redirect-on-Write snapshots, synchronous\/asynchronous replication.<\/p>\n

      The service VM provides access to the WEB interface for managing the HyperFlex subsystem. There is integration with vCenter, and most everyday tasks can be performed from there, but datastores are more conveniently managed from a separate web interface if you\u2019ve switched to the fast HTML5 interface, or through the full Flash client with complete integration. In the service web interface, you can view system performance and detailed status.<\/p>\n

      \"Admin
      \n
      \nThere is another type of node in the cluster\u2014compute nodes. These can be rack-mounted or blade servers without built-in disks. On these servers, you can run VMs whose data is stored on disk servers. From the perspective of data access, there is no difference between the types of nodes, as the architecture abstracts from the physical location of the data. The maximum ratio of compute nodes to storage nodes is 2:1.<\/p>\n

      Using compute nodes increases flexibility when scaling the cluster's resources: we are not required to purchase nodes with disks if we only need CPU\/RAM. Additionally, we can add a blade chassis and save on server rack placement.<\/p>\n

      As a result, we have a hyper-converged platform with the following features:<\/p>\n