To je mit, ki je precej pogost na področju strežniške strojne opreme. V praksi so hiperkonvergirane rešitve (ko je vse v enem) potrebne za marsikaj. Zgodovinsko gledano sta prvi arhitekturi za svoje storitve razvila Amazon in Google. Potem je bila ideja narediti računalniško farmo iz enakih vozlišč, od katerih je vsako imelo svoje diske. Vse to je združila neka programska oprema za oblikovanje sistema (hipervizor) in razdeljena na virtualne stroje. Glavni cilj je čim manj truda za servisiranje enega vozlišča in čim manj težav pri skaliranju: samo kupite še tisoč ali dva enakih strežnikov in jih povežite v bližini. V praksi gre za osamljene primere, veliko pogosteje pa govorimo o manjšem številu vozlišč in nekoliko drugačni arhitekturi.
A plus ostaja enak – neverjetna enostavnost skaliranja in upravljanja. Slaba stran je, da različne naloge različno porabljajo vire in na nekaterih mestih bo veliko lokalnih diskov, na drugih bo malo RAM-a in tako naprej, to pomeni, da se bo za različne vrste nalog izkoriščenost virov zmanjšala.
Izkazalo se je, da za enostavno nastavitev plačate 10–15 % več. To je tisto, kar je sprožilo mit v naslovu. Dolgo smo iskali, kje bi tehnologijo optimalno uporabili, in jo tudi našli. Dejstvo je, da Cisco ni imel svojih sistemov za shranjevanje podatkov, ampak so želeli popoln trg strežnikov. In naredili so Cisco Hyperflex – rešitev z lokalnim shranjevanjem na vozliščih.
In to se je nenadoma izkazalo za zelo dobro rešitev za rezervne podatkovne centre (Disaster Recovery). Zdaj vam bom povedal zakaj in kako. In pokazal vam bom teste grozdov.
Kjer je potrebno
Hiperkonvergenca je:
- Prenos diskov v računalniška vozlišča.
- Popolna integracija podsistema za shranjevanje s podsistemom za virtualizacijo.
- Prenos/integracija z omrežnim podsistemom.
Ta kombinacija vam omogoča implementacijo številnih funkcij sistema za shranjevanje na ravni virtualizacije in vse iz enega nadzornega okna.
V našem podjetju so projekti oblikovanja redundantnih podatkovnih centrov zelo iskani, pogosto pa se zaradi kopice replikacijskih možnosti (do metroclustra) odločijo za hiperkonvergentno rešitev.
V primeru rezervnih podatkovnih centrov običajno govorimo o oddaljenem objektu na lokaciji na drugi strani mesta ali povsem v drugem mestu. Omogoča obnovitev kritičnih sistemov v primeru delne ali popolne okvare glavnega podatkovnega centra. Podatki o prodaji se tam nenehno replicirajo, ta replikacija pa je lahko na ravni aplikacije ali na ravni blokovne naprave (shrambe).
Zato bom zdaj govoril o zasnovi sistema in testih, nato pa o nekaj scenarijih uporabe v resničnem življenju s podatki o prihrankih.
Testi
Naš primerek je sestavljen iz štirih strežnikov, od katerih ima vsak 10 SSD diskov po 960 GB. Obstaja namenski disk za predpomnjenje zapisovalnih operacij in shranjevanje storitvenega virtualnega stroja. Sama rešitev je četrta različica. Prvi je odkrito surov (sodeč po ocenah), drugi je vlažen, tretji je že precej stabilen, tega pa lahko imenujemo izdaja po koncu beta testiranja za širšo javnost. Med testiranjem nisem opazil nobenih težav, vse deluje kot ura.
Spremembe v v4Odpravljenih je kup hroščev.
Sprva je platforma lahko delovala le s hipervizorjem VMware ESXi in je podpirala majhno število vozlišč. Prav tako se postopek uvajanja ni vedno uspešno končal, nekatere korake je bilo treba znova zagnati, težave so bile pri posodabljanju s starejših različic, podatki v GUI niso bili vedno prikazani pravilno (čeprav še vedno nisem zadovoljen s prikazom grafov uspešnosti ), včasih so se pojavile težave na vmesniku z virtualizacijo.
Zdaj so vse težave iz otroštva odpravljene, HyperFlex lahko obravnava tako ESXi kot Hyper-V, poleg tega pa je mogoče:
- Ustvarjanje raztegnjenega grozda.
- Izdelava grozda za pisarne brez uporabe Fabric Interconnect, od dveh do štirih vozlišč (kupimo samo strežnike).
- Sposobnost dela z zunanjimi sistemi za shranjevanje.
- Podpora za vsebnike in Kubernetes.
- Ustvarjanje območij razpoložljivosti.
- Integracija z VMware SRM, če vgrajena funkcionalnost ni zadovoljiva.
Arhitektura se ne razlikuje veliko od rešitev glavnih konkurentov, ki niso ustvarili kolesa. Vse teče na virtualizacijski platformi VMware ali Hyper-V. Strojna oprema gostuje na lastniških strežnikih Cisco UCS. Obstajajo tisti, ki platformo sovražijo zaradi relativne zapletenosti začetne nastavitve, veliko gumbov, netrivialnega sistema predlog in odvisnosti, obstajajo pa tudi tisti, ki so se naučili zena, jih ideja navdihuje in ne želijo več za delo z drugimi strežniki.
Razmislili bomo o rešitvi za VMware, saj je bila rešitev prvotno ustvarjena zanj in ima več funkcionalnosti, Hyper-V pa je bil dodan sproti, da bi sledili tekmecem in izpolnili pričakovanja trga.
Obstaja gruča strežnikov, polna diskov. Na voljo so diski za shranjevanje podatkov (SSD ali HDD - po vašem okusu in potrebah), na voljo je en SSD disk za predpomnjenje. Pri zapisovanju podatkov v podatkovno shrambo se podatki shranijo na predpomnilniško plast (namenski SSD disk in RAM storitvenega VM). Vzporedno se blok podatkov pošlje vozliščem v gruči (število vozlišč je odvisno od faktorja replikacije gruče). Po potrditvi vseh vozlišč o uspešnem snemanju se potrditev snemanja pošlje v hipervizor in nato v VM. Posneti podatki se v ozadju deduplicirajo, stisnejo in zapišejo na pomnilniške diske. Hkrati se na pomnilniške diske vedno in zaporedno zapisuje velik blok, kar zmanjša obremenitev pomnilniških diskov.
Deduplikacija in stiskanje sta vedno omogočeni in ju ni mogoče onemogočiti. Podatki se berejo neposredno s pomnilniških diskov ali iz predpomnilnika RAM. Če je uporabljena hibridna konfiguracija, se branja shranijo tudi v predpomnilnik na SSD.
Podatki niso vezani na trenutno lokacijo virtualnega stroja in so enakomerno porazdeljeni med vozlišči. Ta pristop vam omogoča enakomerno nalaganje vseh diskov in omrežnih vmesnikov. Obstaja očitna pomanjkljivost: zakasnitve branja ne moremo čim bolj zmanjšati, saj ni zagotovila, da bodo podatki na voljo lokalno. Vendar menim, da je to manjša žrtev v primerjavi s prejetimi ugodnostmi. Poleg tega so omrežne zamude dosegle takšne vrednosti, da praktično ne vplivajo na skupni rezultat.
Za celotno logiko delovanja diskovnega podsistema je odgovoren poseben servisni krmilnik VM Cisco HyperFlex Data Platform, ki je ustvarjen na vsakem skladiščnem vozlišču. V naši servisni konfiguraciji VM je bilo dodeljenih osem vCPU-jev in 72 GB RAM-a, kar ni tako malo. Naj vas spomnim, da ima sam gostitelj 28 fizičnih jeder in 512 GB RAM-a.
Storitveni VM ima dostop do fizičnih diskov neposredno tako, da krmilnik SAS posreduje VM. Komunikacija s hipervizorjem poteka prek posebnega modula IOVisor, ki prestreza V/I operacije, in z uporabo agenta, ki omogoča pošiljanje ukazov v API hipervizorja. Agent je odgovoren za delo s posnetki in kloni HyperFlex.
Diskovni viri so nameščeni v hipervizorju kot deli NFS ali SMB (odvisno od vrste hipervizorja, uganite, kateri je kje). Pod pokrovom pa je to porazdeljeni datotečni sistem, ki vam omogoča dodajanje funkcij polnopravnih sistemov za shranjevanje za odrasle: tanko dodeljevanje prostornine, stiskanje in deduplikacija, posnetki s tehnologijo Redirect-on-Write, sinhrono/asinhrono podvajanje.
Storitveni VM omogoča dostop do WEB vmesnika za upravljanje podsistema HyperFlex. Obstaja integracija z vCenter in iz njega je mogoče izvajati večino vsakodnevnih opravil, vendar je podatkovne shrambe na primer bolj priročno izrezati iz ločene spletne kamere, če ste že preklopili na hiter vmesnik HTML5 ali uporabite polnopravnega odjemalca Flash s popolno integracijo. V servisni spletni kameri si lahko ogledate delovanje in podrobno stanje sistema.
Obstaja še ena vrsta vozlišč v gruči - računalniška vozlišča. To so lahko rack ali blade strežniki brez vgrajenih diskov. Ti strežniki lahko poganjajo VM, katerih podatki so shranjeni na strežnikih z diski. Z vidika dostopa do podatkov ni razlike med tipi vozlišč, ker arhitektura vključuje abstrakcijo od fizične lokacije podatkov. Največje razmerje med računalniškimi vozlišči in vozlišči za shranjevanje je 2:1.
Uporaba računalniških vozlišč poveča prilagodljivost pri skaliranju virov gruče: ni nam treba kupovati dodatnih vozlišč z diski, če potrebujemo samo CPE/RAM. Poleg tega lahko dodamo blade kletko in prihranimo pri rack postavitvi strežnikov.
Kot rezultat imamo hiperkonvergirano platformo z naslednjimi funkcijami:
- Do 64 vozlišč v gruči (do 32 vozlišč za shranjevanje).
- Najmanjše število vozlišč v gruči je tri (dve za gručo Edge).
- Mehanizem redundance podatkov: zrcaljenje s faktorjem replikacije 2 in 3.
- Metro grozd.
- Asinhrona replikacija VM v drugo gručo HyperFlex.
- Orkestracija preklapljanja navideznih strojev v oddaljeni podatkovni center.
- Izvorni posnetki s tehnologijo Redirect-on-Write.
- Do 1 PB uporabnega prostora pri faktorju podvajanja 3 in brez deduplikacije. Replikacijskega faktorja 2 ne upoštevamo, ker to ni možnost za resno prodajo.
Še en velik plus je enostavnost upravljanja in uvajanja. Za vse zapletenosti postavitve strežnikov UCS poskrbi specializiran VM, ki so ga pripravili Ciscovi inženirji.
Konfiguracija preskusne mize:
- 2 x Cisco UCS Fabric Interconnect 6248UP kot upravljalni grozd in omrežne komponente (48 vrat, ki delujejo v načinu Ethernet 10G/FC 16G).
- Štirje strežniki Cisco UCS HXAF240 M4.
Lastnosti strežnika:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
mreža
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet vrata
HBA za shranjevanje
Cisco 12G modularni SAS prehodni krmilnik
Shranjevalni diski
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Več možnosti konfiguracijePoleg izbrane strojne opreme so trenutno na voljo naslednje možnosti:
- HXAF240c M5.
- En ali dva CPU-ja od Intel Silver 4110 do Intel Platinum I8260Y. Na voljo druga generacija.
- 24 pomnilniških rež, trakovi od 16 GB RDIMM 2600 do 128 GB LRDIMM 2933.
- Od 6 do 23 podatkovnih diskov, en disk za predpomnjenje, en sistemski disk in en zagonski disk.
Zmogljivost pogonov
- HX-SD960G61X-EV 960 GB 2.5-palčni SSD SSD Enterprise Value 6G (1X vzdržljivost) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5-palčni 6G SATA SSD Enterprise Value (1X vzdržljivost) SAS 3.8 TB.
- Predpomnjenje pogonov
- HX-NVMEXPB-I375 375 GB 2.5-palčni pogon Intel Optane, izjemna zmogljivost in vzdržljivost.
- HX-NVMEHW-H1600* 1.6 TB 2.5 palca Ent. Perf. NVMe SSD (3X vzdržljivost) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5 palca Ent. Perf. 12G SAS SSD (10X vzdržljivost) SAS 400 GB.
- HX-SD800GBENK9** 800 GB 2.5 palca Ent. Perf. 12G SAS SED SSD (10X vzdržljivost) SAS 800 GB.
- HX-SD16T123X-EP 1.6 TB 2.5-palčni 12G SAS SSD za podjetja (3-kratna vzdržljivost).
Sistemski/dnevniški pogoni
- HX-SD240GM1X-EV 240 GB 2.5-palčni 6G SATA SSD Enterprise Value (zahteva nadgradnjo).
Zagonski pogoni
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Povežite se z omrežjem prek 40G, 25G ali 10G Ethernet vrat.
FI je lahko HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Sam test
Za testiranje diskovnega podsistema sem uporabil HCIBench 2.2.1. To je brezplačen pripomoček, ki vam omogoča avtomatizacijo ustvarjanja obremenitve iz več virtualnih strojev. Sama obremenitev se ustvari z običajnim fio.
Naš grozd sestavljajo štiri vozlišča, replikacijski faktor 3, vsi diski so Flash.
Za testiranje sem ustvaril štiri podatkovne shrambe in osem virtualnih strojev. Za teste pisanja se predpostavlja, da disk za predpomnjenje ni poln.
Rezultati testa so naslednji:
100 % branje 100 % naključno
0% branje 100% naključno
Globina bloka/čakalne vrste
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36 ms 374348 IOPS
2.47 ms 414116 IOPS
4,86 ms 420180 IOPS
2,22 ms 57408 IOPS
3,09 ms 82744 IOPS
5,02 ms 101824 IPOS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376,484 IOPS
5,47 ms 373,176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16K
0,77 ms 164116 IOPS
1,12 ms 228328 IOPS
1,9 ms 268140 IOPS
3,96 ms 258480 IOPS
3,8 ms 33640 IOPS
6,97 ms 36696 IOPS
11,35 ms 45060 IOPS
32K
1,07 ms 119292 IOPS
1,79 ms 142888 IOPS
3,56 ms 143760 IOPS
7,17 ms 17810 IOPS
11,96 ms 21396 IOPS
64K
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
Krepko označuje vrednosti, po katerih ni povečanja produktivnosti, včasih je vidna celo degradacija. To je posledica dejstva, da smo omejeni z zmogljivostjo omrežja/krmilnikov/diskov.
- Zaporedno branje 4432 MB/s.
- Zaporedno pisanje 804 MB/s.
- Če en krmilnik odpove (odpoved virtualnega stroja ali gostitelja), je padec zmogljivosti dvakraten.
- Če pomnilniški disk odpove, je črpanje 1/3. Obnova diska zahteva 5 % virov vsakega krmilnika.
Na majhnem bloku smo omejeni z zmogljivostjo krmilnika (virtualnega stroja), njegov CPE je obremenjen 100 %, ko se blok poveča, pa smo omejeni s pasovno širino vrat. 10 Gbps ni dovolj za sprostitev potenciala sistema AllFlash. Na žalost nam parametri priloženega demo stojala ne omogočajo preizkusa delovanja pri 40 Gbit/s.
Po mojem vtisu iz testov in proučevanja arhitekture, zaradi algoritma, ki postavlja podatke med vse gostitelje, dobimo razširljivo, predvidljivo zmogljivost, vendar je to tudi omejitev pri branju, saj bi se dalo iz lokalnih diskov iztisniti več, tukaj lahko prihrani bolj produktivno omrežje, na voljo je na primer FI pri 40 Gbit/s.
Prav tako je lahko omejitev en disk za predpomnjenje in deduplikacijo; pravzaprav lahko v tej preskusni napravi pišemo na štiri diske SSD. Super bi bilo, če bi lahko povečali število pogonov za predpomnjenje in videli razliko.
Prava uporaba
Če želite organizirati rezervni podatkovni center, lahko uporabite dva pristopa (ne upoštevamo postavitve varnostne kopije na oddaljeno mesto):
- Aktivno-pasivno. Vse aplikacije gostujejo v glavnem podatkovnem centru. Replikacija je sinhrona ali asinhrona. Če glavni podatkovni center odpove, moramo aktivirati rezervnega. To je mogoče storiti ročno/skripti/orkestracijske aplikacije. Tu bomo dobili RPO, ki je sorazmeren s frekvenco replikacije, RTO pa je odvisen od reakcije in veščin skrbnika ter kakovosti razvoja/odpravljanja napak načrta preklopa.
- Aktivno-aktivno. V tem primeru obstaja le sinhrona replikacija; razpoložljivost podatkovnih centrov določa kvorum/arbiter, ki se nahaja strogo na tretjem mestu. RPO = 0, RTO pa lahko doseže 0 (če aplikacija to omogoča) ali enako času samodejnega preklopa vozlišča v virtualizacijski gruči. Na ravni virtualizacije se ustvari raztegnjena (Metro) gruča, ki zahteva Active-Active shranjevanje.
Običajno vidimo, da imajo naročniki že implementirano arhitekturo s klasičnim pomnilniškim sistemom v glavnem podatkovnem centru, zato oblikujemo drugega za replikacijo. Kot sem že omenil, Cisco HyperFlex ponuja asinhrono replikacijo in ustvarjanje raztegnjenih virtualizacijskih gruč. Hkrati pa ne potrebujemo namenskega pomnilniškega sistema srednjega in višjega nivoja z dragimi replikacijskimi funkcijami in aktivnim aktivnim dostopom do podatkov na dveh pomnilniških sistemih.
Scenarij 1: Imamo primarni in rezervni podatkovni center, virtualizacijsko platformo na VMware vSphere. Vsi produktivni sistemi se nahajajo v glavnem podatkovnem centru, replikacija virtualnih strojev pa se izvaja na ravni hipervizorja, s čimer se boste izognili temu, da bi VM ostali vklopljeni v rezervnem podatkovnem centru. Podvajamo baze podatkov in posebne aplikacije z uporabo vgrajenih orodij in ohranjamo vklopljene VM. Če glavni podatkovni center odpove, zaženemo sisteme v rezervnem podatkovnem centru. Menimo, da imamo približno 100 virtualnih strojev. Medtem ko primarni podatkovni center deluje, lahko podatkovni center v pripravljenosti izvaja testna okolja in druge sisteme, ki jih je mogoče zaustaviti, če primarni podatkovni center preklopi. Možno je tudi, da uporabimo dvosmerno replikacijo. S strojnega vidika se ne bo nič spremenilo.
V primeru klasične arhitekture bomo v vsak podatkovni center namestili hibridni sistem za shranjevanje z dostopom preko FibreChannel, tiering, deduplikacijo in stiskanje (vendar ne na spletu), 8 strežnikov za vsako mesto, 2 stikali FibreChannel in 10G Ethernet. Za replikacijo in upravljanje preklapljanja v klasični arhitekturi lahko uporabimo orodja VMware (Replication + SRM) ali orodja tretjih oseb, ki bodo nekoliko cenejša in včasih bolj priročna.
Slika prikazuje diagram.
Pri uporabi Cisco HyperFlex se pridobi naslednja arhitektura:
Za HyperFlex sem uporabil strežnike z velikimi viri CPE/RAM, ker ... Nekateri viri bodo šli v VM krmilnika HyperFlex; kar zadeva CPE in pomnilnik, sem celo nekoliko na novo konfiguriral konfiguracijo HyperFlex, da se ne bi poigraval s Ciscom in zagotovil vire za preostale VM. Lahko pa opustimo stikala FibreChannel in ne bomo potrebovali ethernetnih vrat za vsak strežnik, lokalni promet se preklaplja znotraj FI.
Rezultat je bila naslednja konfiguracija za vsak podatkovni center:
Strežniki
8 x 1U strežnik (384 GB RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
SHD
Hibridni sistem za shranjevanje s FC Front-End (20 TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet stikalo 10G 12 portov
-
SAN
2 x FC stikalo 32/16Gb 24 portov
2 x Cisco UCS FI 6332
Licence
VMware Ent Plus
Replikacija in/ali orkestracija preklapljanja VM
VMware Ent Plus
Nisem zagotovil licenc za programsko opremo za podvajanje za Hyperflex, ker je ta na voljo takoj po namestitvi.
Za klasično arhitekturo sem izbral prodajalca, ki se je uveljavil kot kvaliteten in poceni proizvajalec. Za obe možnosti sem uporabil standardni popust za določeno rešitev in posledično dobil realne cene.
Rešitev Cisco HyperFlex se je izkazala za 13 % cenejša.
Scenarij 2: vzpostavitev dveh aktivnih podatkovnih centrov. V tem scenariju načrtujemo raztegnjeno gručo na VMware.
Klasično arhitekturo sestavljajo strežniki za virtualizacijo, SAN (protokol FC) in dva sistema za shranjevanje, ki lahko bereta in pišeta na prostor, razpet med njima. Na vsak skladiščni sistem postavimo uporabno kapaciteto za shranjevanje.
Pri HyperFlexu preprosto ustvarimo Stretch Cluster z enakim številom vozlišč na obeh mestih. V tem primeru se uporabi faktor podvajanja 2+2.
Rezultat je naslednja konfiguracija:
klasična arhitektura
HyperFlex
Strežniki
16 x 1U strežnik (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)
16 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
SHD
2 x sistem za shranjevanje AllFlash (150 TB SSD)
-
LAN
4 x Ethernet stikalo 10G 24 portov
-
SAN
4 x FC stikalo 32/16Gb 24 portov
4 x Cisco UCS FI 6332
Licence
VMware Ent Plus
VMware Ent Plus
Pri vseh izračunih nisem upošteval omrežne infrastrukture, stroškov podatkovnega centra itd.: ti bodo enaki za klasično arhitekturo in za rešitev HyperFlex.
Glede stroškov se je HyperFlex izkazal za 5% dražji. Tukaj je treba omeniti, da sem imel glede virov CPE/RAM za Cisco odstopanje, ker sem v konfiguraciji enakomerno zapolnil kanale krmilnika pomnilnika. Strošek je nekoliko višji, vendar ne za red velikosti, kar jasno nakazuje, da hiperkonvergenca ni nujno »igrača za bogate«, temveč lahko konkurira standardnemu pristopu k izgradnji podatkovnega centra. To bo morda zanimivo tudi za tiste, ki že imajo strežnike Cisco UCS in pripadajočo infrastrukturo zanje.
Med prednostmi dobimo odsotnost stroškov za administracijo SAN in sistemov za shranjevanje, spletno kompresijo in deduplikacijo, enotno vstopno točko za podporo (virtualizacija, strežniki, so tudi sistemi za shranjevanje), prihranek prostora (vendar ne v vseh scenarijih), poenostavitev delovanja.
Kar zadeva podporo, jo tukaj dobite od enega prodajalca - Cisco. Glede na izkušnje s strežniki Cisco UCS mi je všeč, na HyperFlexu mi ga ni bilo treba odpreti, vse je delovalo enako. Inženirji se hitro odzovejo in lahko rešijo ne le tipične težave, ampak tudi zapletene robne primere. Včasih se obrnem na njih z vprašanji: "Je to mogoče narediti, privijte?" ali »Tu sem nekaj konfiguriral in noče delovati. Pomoč!" - tam bodo potrpežljivo našli potreben vodnik in opozorili na pravilna dejanja, ne bodo odgovorili: "Rešujemo samo težave s strojno opremo."
reference
- Moj mail - [e-pošta zaščitena]
Vir: www.habr.com