Moien, Habr Lieser. Mat dësem Artikel öffnen mir eng Serie déi iwwer den hyperkonvergéierte System AERODISK vAIR schwätzt, dee mir entwéckelt hunn. Am Ufank wollte mir alles iwwer alles am éischten Artikel erzielen, awer de System ass zimlech komplex, sou datt mir den Elefant an Deeler iessen.
Loosst eis d'Geschicht mat der Geschicht vun der Schafung vum System ufänken, an den ARDFS Dateisystem verdéiwen, deen d'Basis vu vAIR ass, an och e bëssen iwwer d'Positionéierung vun dëser Léisung um russesche Maart schwätzen.
An zukünfteg Artikele wäerte mir méi detailléiert iwwer verschidden architektonesch Komponenten schwätzen (Cluster, Hypervisor, Lastbalancer, Iwwerwaachungssystem, asw.), de Konfiguratiounsprozess, d'Lizenzprobleemer erhéijen, separat Crash Tester weisen an, natierlech, iwwer Laaschttesten schreiwen an Gréisst. Mir wäerten och e separaten Artikel op d'Communautéit Versioun vu vAIR widmen.
Ass Aerodisk eng Geschicht iwwer Späichersystemer? Oder firwat hu mir iwwerhaapt ugefaang Hyperkonvergenz ze maachen?
Am Ufank koum d'Iddi fir eis eege Hyperkonvergenz ze kreéieren iergendwou ronderëm 2010. Zu där Zäit gouf et weder Aerodisk nach ähnlech Léisungen (kommerziell Boxed Hyperconverged Systemer) um Maart. Eis Aufgab war déi folgend: aus enger Rei vu Serveren mat lokalen Disken, vereenegt duerch eng Interconnect iwwer den Ethernet Protokoll, war et néideg fir eng erweidert Späichere ze kreéieren an do virtuell Maschinnen an e Softwarenetz ze starten. All dëst huet missen ouni Späichersystemer ëmgesat ginn (well et einfach keng Sue fir Späichersystemer a seng Hardware waren, a mir hunn eis eegen Späichersystemer nach net erfonnt).
Mir hunn vill Open Source Léisunge probéiert an endlech dëse Problem geléist, awer d'Léisung war ganz komplex a schwéier ze widderhuelen. Ausserdeem war dës Léisung an der Kategorie "Funkt et? Net beréieren! Dofir, nodeems se dëse Problem geléist hunn, hu mir d'Iddi net weider entwéckelt fir d'Resultat vun eiser Aarbecht an e vollwäertegt Produkt ze transforméieren.
No deem Tëschefall si mir vun dëser Iddi ewech gaang, mä mir haten nach ëmmer d'Gefill, datt dëse Problem komplett léisbar wier, an d'Virdeeler vun esou enger Léisung méi wéi evident waren. Duerno hunn déi verëffentlecht HCI Produkter vun auslännesche Firmen nëmmen dëst Gefill bestätegt.
Dofir, an der Mëtt vum 2016, hu mir zréck op dës Aufgab als Deel vun der Schafung vun engem vollwäertege Produkt. Deemools hu mir nach keng Relatioune mat Investisseuren, also hu mir en Entwécklungsstand fir eis eegen net ganz grouss Suen ze kafen. Nodeems mir benotzt Serveren a Schalter op Avito gesammelt hunn, hu mir op d'Geschäft komm.
D'Haaptaufgab vun der éischter Aufgab war eisen eegenen, wann och einfach, awer eisen eegene Dateiesystem ze kreéieren, deen automatesch a gläichméisseg Daten a Form vu virtuelle Blocken op der n. Zuel vu Clusternoden verdeele konnt, déi duerch eng Interconnect iwwer Ethernet verbonne sinn. Zur selwechter Zäit soll de FS gutt a liicht skaléieren an onofhängeg vun ugrenzend Systemer sinn, d.h. aus vAIR a Form vun "nëmmen eng Stockage facility" ausgebaut ginn.
Éischt vAIR Konzept
Mir hunn bewosst d'Benotzung vu fäerdege Open Source Léisunge fir d'Organisatioun vun gestreckte Lagerung (Ceph, Gluster, Glanz an dergläiche) zugonschte vun eiser eegener Entwécklung opginn, well mir scho vill Projetserfahrung mat hinnen haten. Natierlech sinn dës Léisunge selwer exzellent, a ier mer un Aerodisk geschafft hunn, hu mir méi wéi een Integratiounsprojet mat hinnen ëmgesat. Awer et ass eng Saach fir eng spezifesch Aufgab fir ee Client ëmzesetzen, Personal ze trainéieren a vläicht d'Ënnerstëtzung vun engem grousse Verkeefer ze kafen, an eng ganz aner Saach fir e liicht replizéiert Produkt ze kreéieren dee fir verschidden Aufgaben benotzt gëtt, déi mir als Verkeefer, kënne souguer iwwer eis selwer wëssen, wäerte mir net. Fir den zweeten Zweck waren existent Open Source Produkter net fir eis gëeegent, also hu mir décidéiert fir e verdeelt Dateiesystem selwer ze kreéieren.
Zwee Joer méi spéit hunn e puer Entwéckler (déi d'Aarbecht op vAIR mat der Aarbecht um klassesche Engine Storage System kombinéiert hunn) e gewësse Resultat erreecht.
Bis 2018 hu mir en einfachen Dateiesystem geschriwwen an et mat der néideger Hardware ergänzt. De System kombinéiert physesch (lokal) Disken vu verschiddene Serveren an engem flaache Pool iwwer eng intern Interconnect a "geschnidden" se a virtuelle Blocken, duerno goufen Blockapparaten mat ënnerschiddleche Grad vu Feelertoleranz aus de virtuelle Blocken erstallt, op deenen virtuelle geschaf goufen. an ausgefouert mat de KVM Hypervisor Autoen.
Mir hunn eis net ze vill mam Numm vum Dateiesystem gestéiert an hunn et kuerz ARDFS genannt (rieden wat et steet))
Dëse Prototyp huet gutt ausgesinn (net visuell, natierlech, et war nach kee visuellen Design) an huet gutt Resultater wat d'Performance an d'Skaléierung ugeet. No dem éischte richtege Resultat hu mir dëse Projet a Bewegung gesat, e vollwäertegt Entwécklungsëmfeld an eng separat Equipe organiséiert, déi nëmme mat vAIR beschäftegt huet.
Just zu där Zäit war d'allgemeng Architektur vun der Léisung reift, déi nach net gréisser Ännerunge gemaach huet.
Daucht an den ARDFS Dateisystem
ARDFS ass d'Fundament vu vAIR, déi verdeelt, Feeler-tolerant Datelagerung iwwer de ganze Cluster ubitt. Ee vun (awer net déi eenzeg) ënnerschiddlech Feature vun ARDFS ass datt et keng zousätzlech dedizéierten Servere fir Metadaten a Gestioun benotzt. Dëst war ursprénglech konzipéiert fir d'Konfiguratioun vun der Léisung a fir seng Zouverlässegkeet ze vereinfachen.
Stockage Struktur
Bannent all Wirbelen vum Cluster organiséiert ARDFS e logesche Pool aus all verfügbaren Disk Space. Et ass wichteg ze verstoen datt e Pool nach net Daten oder formatéiert Raum ass, awer einfach Markup, d.h. All Node mat vAIR installéiert, wann se an de Stärekoup bäigefüügt ginn, ginn automatesch an de gemeinsame ARDFS-Pool bäigefüügt an d'Diskressourcen ginn automatesch iwwer de ganze Cluster gedeelt (a verfügbar fir zukünfteg Datelagerung). Dës Approche erlaabt Iech Noden op der Flucht ze addéieren an ze läschen ouni e seriöen Impakt op de scho lafende System. Déi. de System ass ganz einfach "an Zillen" ze skaléieren, d'Noden am Cluster bäizefügen oder ze läschen wann néideg.
Virtuell Disken (Späicherobjete fir virtuell Maschinnen) ginn uewen um ARDFS-Pool bäigefüügt, déi aus virtuelle Blöcke vu 4 Megabytes an der Gréisst gebaut ginn. Virtuell Disken späicheren direkt Daten. De Feeler Toleranz Schema ass och op der virtueller Scheif Niveau gesat.
Wéi Dir scho scho virgestallt hutt, fir Fehltoleranz vum Disk-Subsystem, benotze mir net d'Konzept vun RAID (Redundant Array vun onofhängege Disks), awer benotzen RAIN (Redundant Array vun onofhängege Noden). Déi. Feeler Toleranz gëtt gemooss, automatiséiert a geréiert baséiert op den Noden, net d'Disken. Disks, natierlech, sinn och e Späicherobjekt, si, wéi alles anescht, iwwerwaacht ginn, Dir kënnt all Standardoperatioune mat hinnen ausféieren, dorënner d'Versammlung vun engem lokalen Hardware RAID, awer de Cluster funktionnéiert speziell op Noden.
An enger Situatioun wou Dir wierklech Razzia wëllt (Zum Beispill, engem Szenario, datt MÉI Feeler op kleng Stärekéip ënnerstëtzt), näischt verhënnert Dir aus engem benotzen lokal Razzia controllers, a Gebai gestreckt Stockage an engem Reen Architektur op erop. Dëst Szenario ass zimmlech live a gëtt vun eis ënnerstëtzt, also wäerte mir doriwwer an engem Artikel iwwer typesch Szenarie fir vAIR benotzen.
Stockage Feeler Toleranz Scheme
Et kënnen zwee Feeler Toleranzschemae fir virtuelle Disken am vAIR sinn:
1) Replikatiounsfaktor oder einfach Replikatioun - dës Method vu Feelertoleranz ass sou einfach wéi e Stéck an e Seel. Synchronesch Replikatioun gëtt tëscht Noden mat engem Faktor vun 2 (2 Exemplare pro Cluster) oder 3 (3 Exemplare respektiv). RF-2 erlaabt eng virtuell Scheif den Echec vun engem Node am Stärekoup ze widderstoen, awer "ësst" d'Halschent vum nëtzlechen Volumen, an RF-3 wäert den Echec vun 2 Noden am Stärekoup widderstoen, awer reservéiert 2/3 vun der nëtzlech Volumen fir seng Besoinen. Dëse Schema ass ganz ähnlech wéi RAID-1, dat heescht, eng virtuell Scheif, déi am RF-2 konfiguréiert ass, ass resistent géint den Ausfall vun engem Node am Cluster. An dësem Fall wäert alles gutt sinn mat den Donnéeën an och den I / O wäert net ophalen. Wann de gefallenen Node zréck an de Service kënnt, fänkt automatesch Datenerhuelung / Synchroniséierung un.
Drënner sinn Beispiller vun der Verdeelung vun RF-2 an RF-3 Daten am normalen Modus an an engem Feeler Situatioun.
Mir hunn eng virtuell Maschinn mat enger Kapazitéit vun 8MB vun eenzegaartegen (nëtzlechen) Daten, déi op 4 vAIR Wirbelen leeft. Et ass kloer datt et an der Realitéit onwahrscheinlech ass datt et sou e klengt Volumen gëtt, awer fir e Schema, deen d'Logik vun der Operatioun vun der ARDFS reflektéiert, ass dëst Beispill am meeschte verständlech. AB sinn 4MB virtuelle Blocken déi eenzegaarteg virtuell Maschinndaten enthalen. RF-2 erstellt zwou Exemplare vun dëse Blocken A1 + A2 respektiv B1 + B2. Dës Blöcke sinn "ausgeliwwert" iwwer Wirbelen, vermeit d'Kräizung vun de selwechten Donnéeën op deemselwechten Node, dat heescht, d'Kopie A1 wäert net um selwechten Node wéi d'Kopie A2 sinn. Selwecht mat B1 a B2.
Wann ee vun de Wirbelen klappt (zum Beispill Node Nr. 3, déi eng Kopie vu B1 enthält), gëtt dës Kopie automatesch op den Node ageschalt, wou et keng Kopie vu senger Kopie ass (dat ass eng Kopie vu B2).
Sou kann déi virtuell Scheif (an de VM, deementspriechend) einfach den Echec vun engem Node am RF-2 Schema iwwerliewen.
D'Replikatiounsschema, wärend einfach an zouverlässeg, leid ënner dem selwechte Problem wéi RAID1 - net genuch benotzbar Plaz.
2) Läschkodéierung oder Läschkodéierung (och bekannt als "redundant Kodéierung", "Läschkodéierung" oder "Redundanzcode") existéiert fir de Problem hei uewen ze léisen. EC ass e Redundanzschema dat héich Dateverfügbarkeet mat méi nidderegen Disk Space Overhead am Verglach mat Replikatioun ubitt. De Betribsprinzip vun dësem Mechanismus ass ähnlech wéi RAID 5, 6, 6P.
Beim Kodéierung deelt den EC-Prozess e virtuelle Block (Standard 4MB) an e puer méi kleng "Datenstécker" ofhängeg vum EC Schema (zum Beispill, en 2+1 Schema deelt all 4MB Block an 2 2MB Stécker). Als nächst generéiert dëse Prozess "Paritéitstécker" fir d'"Datenstécker", déi net méi grouss sinn wéi ee vun de virdru gedeelt Deeler. Beim Dekodéierung generéiert EC déi fehlend Stécker andeems se déi "iwwerliewend" Daten iwwer de ganze Stärekoup liesen.
Zum Beispill, eng virtuell Scheif mat engem 2 + 1 EC Schema, implementéiert op 4 Cluster Wirbelen, wäert einfach den Echec vun engem Knuet am Cluster an der selwechter Manéier wéi RF-2 widderstoen. An dësem Fall wäerten d'Overheadkäschte méi niddereg sinn, besonnesch den nëtzlechen Kapazitéitskoeffizient fir RF-2 ass 2, a fir EC 2+1 ass et 1,5.
Fir et méi einfach ze beschreiwen, ass d'Essenz datt de virtuelle Block an 2-8 opgedeelt ass (firwat vun 2 bis 8, kuckt hei ënnen) "Stécker", a fir dës Stécker "Stécker" vun der Paritéit vun engem ähnleche Volumen berechent ginn.
Als Resultat sinn Daten a Paritéit gläichméisseg iwwer all Node vum Stärekoup verdeelt. Zur selwechter Zäit, wéi bei der Replikatioun, verdeelt ARDFS automatesch Daten iwwer Knäppercher sou datt identesch Donnéeën (Kopie vun Daten an hir Paritéit) net um selwechten Node gespäichert ginn, fir d'Chance ze eliminéieren fir Daten ze verléieren wéinst zu der Tatsaach, datt d'Donnéeën an hir Paritéit op eemol op ee Späicherknuet ophalen, deen ausfällt.
Drënner ass e Beispill, mat der selwechter 8 MB virtueller Maschinn a 4 Wirbelen, awer mat engem EC 2+1 Schema.
Block A an B sinn an zwee Stécker vun all 2 MB opgedeelt (zwee well 2+1), dat ass A1+A2 an B1+B2. Am Géigesaz zu enger Replica ass A1 keng Kopie vun A2, et ass e virtuelle Block A, opgedeelt an zwee Deeler, d'selwecht mam Block B. Am Ganzen kréie mir zwee Sätz vu 4MB, déi all zwee zwee MB Stécker enthalen. Als nächst gëtt d'Paritéit fir all eenzel vun dëse Sets mat engem Volume vun net méi wéi engem Stéck (dh 2 MB) berechent, mir kréien eng zousätzlech + 2 Stéck Paritéit (AP a BP). Am Ganzen hu mir 4 × 2 Daten + 2 × 2 Paritéit.
Als nächst sinn d'Stécker "ausgeluecht" ënnert den Noden, sou datt d'Donnéeën net mat hirer Paritéit intersectéieren. Déi. A1 an A2 wäerten net um selwechten Node wéi AP sinn.
Am Fall vun engem Ausfall vun engem Node (zum Beispill och den Drëtten), gëtt de gefallene Block B1 automatesch vun der BP-Paritéit restauréiert, déi um Node Nr. keng B-Paritéit, d.h. Stéck BP. An dësem Beispill ass dëst Node Nr 2
Ech si sécher datt de Lieser eng Fro huet:
"Alles wat Dir beschriwwen hutt ass laang souwuel vu Konkurrenten wéi an Open Source Léisungen ëmgesat ginn, wat ass den Ënnerscheed tëscht Ärer Ëmsetzung vun EC an ARDFS?"
An da ginn et interessant Features vun ARDFS.
Läschen Kodéierung mat engem Fokus op Flexibilitéit
Am Ufank hu mir e relativ flexibelen EC X+Y Schema zur Verfügung gestallt, wou X gläich ass mat enger Zuel vun 2 bis 8, an Y gläich ass mat enger Zuel vun 1 bis 8, awer ëmmer manner wéi oder gläich wéi X. fir Flexibilitéit. D'Erhéijung vun der Unzuel vun den Datenstécker (X), an deenen de virtuelle Block opgedeelt ass, erlaabt d'Overheadkäschten ze reduzéieren, dat heescht d'Erhéijung vum benotzbare Raum.
D'Erhéijung vun der Zuel vu Paritéitstécker (Y) erhéicht d'Zouverlässegkeet vun der virtueller Scheif. Wat de Y-Wäert méi grouss ass, wat méi Noden am Stärekoup versoen. Natierlech reduzéiert d'Erhéijung vum Paritéitsvolumen d'Quantitéit vun der benotzbarer Kapazitéit, awer dëst ass e Präis fir Zouverlässegkeet ze bezuelen.
D'Ofhängegkeet vun der Leeschtung op EC Circuiten ass bal direkt: wat méi "Stécker", wat d'Performance méi niddereg ass, natierlech ass eng equilibréiert Vue néideg.
Dës Approche erlaabt Administrateuren gestreckt Späichere mat maximaler Flexibilitéit ze konfiguréieren. Am ARDFS Pool kënnt Dir all Feeler Toleranz Schemaen an hir Kombinatioune benotzen, déi, eiser Meenung no, och ganz nëtzlech ass.
Drënner ass eng Tabell déi e puer (net all méiglech) RF an EC Schema vergläicht.
D'Tabell weist datt och déi meescht "Terry" Kombinatioun EC 8+7, déi de Verloscht vu bis zu 7 Noden an engem Stärekoup gläichzäiteg erlaabt, manner benotzbar Plaz (1,875 versus 2) wéi Standard Replikatioun "ësst" a schützt 7 Mol besser , wat dëse Schutzmechanismus mécht, obwuel méi komplex ass, vill méi attraktiv an Situatiounen, wou et néideg ass fir maximal Zouverlässegkeet a Bedingungen vu limitéierter Disk Space ze garantéieren. Zur selwechter Zäit musst Dir verstoen datt all "Plus" op X oder Y eng zousätzlech Leeschtungsoverhead wäert sinn, also am Dräieck tëscht Zouverlässegkeet, Spuer a Leeschtung musst Dir ganz suergfälteg wielen. Aus dësem Grond wäerte mir en separaten Artikel widmen fir d'Kodéierungsgréisst ze läschen.
Zouverlässegkeet an Autonomie vum Dateiesystem
ARDFS leeft lokal op all Wirbelen vum Stärekoup a synchroniséiert se mat hiren eegene Mëttelen duerch engagéierten Ethernet Schnëttplazen. De wichtege Punkt ass datt ARDFS onofhängeg net nëmmen d'Donnéeën synchroniséiert, awer och d'Metadaten am Zesummenhang mat der Späichere. Wärend un ARDFS geschafft hunn, hu mir gläichzäiteg eng Rei vun existente Léisunge studéiert a mir entdeckt datt vill de Dateisystem Meta synchroniséieren mat engem externen verdeelte DBMS, dee mir och fir d'Synchroniséierung benotzen, awer nëmmen Konfiguratiounen, net FS Metadaten (iwwer dëst an aner verbonne Subsystemer) am nächsten Artikel).
Synchroniséierung vun FS Metadaten mat engem externen DBMS ass natierlech eng funktionéierend Léisung, awer dann hänkt d'Konsistenz vun den Daten, déi op ARDFS gespäichert sinn, vun der externer DBMS a sengem Verhalen of (an, éierlech gesoot, et ass eng kapricious Dame), déi an eis Meenung ass schlecht. Firwat? Wann d'FS Metadaten beschiedegt ginn, kënnen d'FS Daten selwer och "Äddi" gesot ginn, also hu mir décidéiert e méi komplexen awer zouverléissege Wee ze huelen.
Mir hunn de Metadaten-Synchroniséierungssubsystem fir ARDFS selwer gemaach, an et lieft komplett onofhängeg vun ugrenzend Subsystemer. Déi. keen aneren Ënnersystem kann ARDFS Daten korrupt. Eiser Meenung no ass dat déi zouverlässegst a korrekt Manéier, awer d'Zäit wäert soen ob dat wierklech esou ass. Zousätzlech gëtt et en zousätzleche Virdeel mat dëser Approche. ARDFS kann onofhängeg vu vAIR benotzt ginn, grad wéi gestreckt Lagerung, déi mir sécherlech an zukünfteg Produkter benotzen.
Als Resultat, duerch d'Entwécklung vun ARDFS, krute mir e flexibelen an zouverléissege Dateiesystem, deen e Choix gëtt, wou Dir op Kapazitéit spuere kënnt oder alles op d'Performance opginn, oder ultra-zouverlässeg Lagerung zu engem verstännegen Käschte maachen, awer d'Leeschtungsfuerderunge reduzéieren.
Zesumme mat enger einfacher Lizenzpolitik an engem flexiblen Liwwermodell (vAIR ass no no no lizenzéiert, an entweder als Software oder als Software Package geliwwert), erlaabt dëst Iech ganz präzis d'Léisung un eng grouss Villfalt vu Client Ufuerderungen unzepassen. dann einfach dëse Gläichgewiicht erhalen.
Wien brauch dëst Wonner?
Engersäits kënne mir soen datt et scho Spiller um Maart sinn, déi sérieux Léisungen am Beräich vun der Hyperkonvergenz hunn, an dat ass wou mir eigentlech higinn. Et schéngt wéi wann dës Ausso richteg ass, MEE ...
Op där anerer Säit, wa mir eraus op d'Felder goen a mat de Clienten kommunizéieren, gesi mir an eise Partner datt dat guer net de Fall ass. Et gi vill Aufgaben fir d'Hyperkonvergenz, op e puer Plazen woussten d'Leit einfach net datt esou Léisunge existéieren, an anere wier et deier, an anerer goufen et net erfollegräich Tester vun alternativen Léisungen, an anerer verbidden se iwwerhaapt ze kafen wéinst Sanktiounen. Am Allgemengen huet sech d'Feld als ongepléckt erausgestallt, also si mir gaang fir virgin Buedem ze erhéijen))).
Wéini ass de Späichersystem besser wéi GCS?
Wéi mir mam Maart schaffen, gi mir dacks gefrot wéini et besser ass e klassesche Schema mat Späichersystemer ze benotzen, a wéini Hyperkonvergent ze benotzen? Vill Firmen, déi GCS produzéieren (besonnesch déi, déi keng Späichersystemer an hirem Portfolio hunn) soen: "Späichersystemer ginn verouderd, nëmmen hyperkonvergéiert!" Dëst ass eng fett Ausso, awer et reflektéiert net ganz d'Realitéit.
An der Wahrheet beweegt de Späichermaart wierklech Richtung Hyperkonvergenz an ähnlech Léisungen, awer et gëtt ëmmer e "awer".
Als éischt kënnen Datenzenteren an IT-Infrastrukturen, déi no dem klassesche Schema mat Späichersystemer gebaut ginn, net einfach nei opgebaut ginn, sou datt d'Moderniséierung an d'Réalisatioun vun esou Infrastrukturen nach ëmmer e Patrimoine fir 5-7 Joer ass.
Zweetens, d'Infrastruktur, déi am Moment zum gréissten Deel gebaut gëtt (dat heescht d'russesch Federatioun) ass no dem klassesche Schema gebaut mat Späichersystemer, an net well d'Leit net iwwer Hyperkonvergenz wëssen, mee well den Hyperkonvergenzmaart nei ass, Léisungen a Standarden sinn nach net etabléiert, IT Leit sinn nach net trainéiert, si hu wéineg Erfahrung, mä si mussen Daten Zentren hei an elo bauen. An dësen Trend wäert nach 3-5 Joer daueren (an dann eng aner Legacy, kuckt Punkt 1).
Drëttens gëtt et eng reng technesch Begrenzung an zousätzlech kleng Verspéidungen vun 2 Millisekonnen pro Schreiwen (ausser de lokalen Cache, natierlech), déi d'Käschte vun der verdeelerter Späichere sinn.
Gutt, loosst eis net iwwer d'Benotzung vu grousse kierperleche Serveren vergiessen déi vertikal Skaléieren vum Disk Subsystem gär hunn.
Et gi vill noutwendeg a populär Aufgaben wou Späichersystemer sech besser behuelen wéi GCS. Hei sinn natierlech déi Hiersteller, déi keng Späichersystemer an hirem Produktportfolio hunn, net mat eis averstanen, awer mir si prett raisonnabel ze streiden. Natierlech wäerte mir als Entwéckler vu béide Produkter definitiv Späichersystemer a GCS an enger vun eisen zukünftege Publikatiounen vergläichen, wou mir kloer weisen wat besser ass a wéi enge Konditiounen.
A wou wäerte hyperkonvergéiert Léisunge besser funktionnéieren wéi Späichersystemer?
Baséierend op de Punkten hei uewen, kënnen dräi offensichtlech Conclusiounen gezunn ginn:
- Wou eng zousätzlech 2 Millisekonnen Latenz fir Opnam, déi konsequent an all Produkt geschitt (elo schwätze mer net vu Synthetik, Nanosekonnen kënnen op Synthetik gewisen ginn), onkritesch sinn, ass hyperkonvergent gëeegent.
- Wou d'Laascht vu grousse physikalesche Serveren a vill kleng virtuelle kënnen ëmgewandelt ginn an ënner Noden verdeelt ginn, wäert d'Hyperkonvergenz och do gutt funktionnéieren.
- Wou horizontal Skaléieren eng méi héich Prioritéit ass wéi vertikal Skalen, wäert GCS et och gutt do maachen.
Wat sinn dës Léisungen?
- All Standard Infrastrukturservicer (Verzeichnisservice, Mail, EDMS, Dateiserver, kleng oder mëttel ERP a BI Systemer, etc.). Mir nennen dëst "allgemeng Informatik".
- D'Infrastruktur vu Cloud Provider, wou et néideg ass fir séier a standardiséiert horizontal auszebauen an einfach eng grouss Zuel vu virtuelle Maschinnen fir Clienten ze "schneiden".
- Virtuell Desktop-Infrastruktur (VDI), wou vill kleng Benotzer virtuell Maschinnen lafen a roueg an engem eenheetleche Cluster "schwiewen".
- Branch Netzwierker, wou all Branche eng Standard, Feeler-tolerant, awer preiswert Infrastruktur vu 15-20 virtuelle Maschinnen brauch.
- All verdeelt Informatik (Big Data Services, zum Beispill). Wou d'Laascht net "an d'Déift" geet, mee "an d'Breet".
- Test Ëmfeld wou zousätzlech kleng Verspéidungen akzeptabel sinn, awer et gi Budgetsbeschränkungen, well dës Tester sinn.
Am Moment ass et fir dës Aufgaben déi mir AERODISK vAIR gemaach hunn an et ass op hinnen déi mir fokusséieren (erfollegräich bis elo). Vläicht ännert sech dat geschwënn, well ... d'Welt steet net roueg.
Also ...
Dëst fäerdeg den éischten Deel vun enger grousser Serie vun Artikelen am nächsten Artikel wäerte mir iwwer d'Architektur vun der Léisung an d'Komponenten schwätzen.
Mir begréissen Froen, Virschléi a konstruktiv Streidereien.
Source: will.com