Toto je mýtus, ktorý je v oblasti serverového hardvéru celkom bežný. V praxi sú hyperkonvergované riešenia (keď je všetko v jednom) potrebné na veľa vecí. Historicky prvé architektúry vyvinuli Amazon a Google pre svoje služby. Potom bola myšlienka vytvoriť výpočtovú farmu z rovnakých uzlov, z ktorých každý mal svoje vlastné disky. To všetko zjednotil nejaký systémotvorný softvér (hypervízor) a rozdelil sa na virtuálne stroje. Hlavným cieľom je minimálne úsilie na obsluhu jedného uzla a minimum problémov pri škálovaní: stačí kúpiť ďalších tisíc alebo dva rovnaké servery a pripojiť ich v blízkosti. V praxi ide o ojedinelé prípady a oveľa častejšie hovoríme o menšom počte uzlov a trochu inej architektúre.
Ale plus zostáva rovnaké - neuveriteľná jednoduchosť škálovania a správy. Nevýhodou je, že rôzne úlohy spotrebúvajú zdroje rôzne a na niektorých miestach bude veľa lokálnych diskov, na iných bude málo RAM atď., To znamená, že pri rôznych typoch úloh sa využitie zdrojov zníži.
Ukázalo sa, že za jednoduché nastavenie zaplatíte o 10–15 % viac. To je to, čo vyvolalo mýtus v názve. Dlho sme hľadali, kde by sa technológia optimálne uplatnila a našli sme ju. Faktom je, že Cisco nemalo svoje vlastné úložné systémy, ale chcelo úplný serverový trh. A vytvorili Cisco Hyperflex – riešenie s lokálnym úložiskom na uzloch.
A to sa zrazu ukázalo ako veľmi dobré riešenie pre zálohovacie dátové centrá (Disaster Recovery). Teraz vám poviem prečo a ako. A ukážem vám klastrové testy.
Kde treba
Hyperkonvergencia je:
- Prenos diskov do výpočtových uzlov.
- Plná integrácia úložného subsystému s virtualizačným subsystémom.
- Prenos/integrácia so sieťovým subsystémom.
Táto kombinácia vám umožňuje implementovať mnoho funkcií úložného systému na úrovni virtualizácie a to všetko z jedného ovládacieho okna.
V našej spoločnosti sú projekty na navrhovanie redundantných dátových centier veľmi žiadané a často sa volí hyperkonvergované riešenie kvôli množstvu možností replikácie (až po metrocluster) hneď po vybalení.
V prípade záložných dátových centier zvyčajne hovoríme o vzdialenom zariadení na mieste na druhej strane mesta alebo úplne v inom meste. Umožňuje vám obnoviť kritické systémy v prípade čiastočného alebo úplného zlyhania hlavného dátového centra. Údaje o predaji sa tam neustále replikujú a táto replikácia môže byť na úrovni aplikácie alebo na úrovni blokového zariadenia (úložiska).
Preto teraz budem hovoriť o návrhu systému a testoch a potom o niekoľkých scenároch aplikácie v reálnom živote s údajmi o úsporách.
skúšky
Naša inštancia pozostáva zo štyroch serverov, z ktorých každý má 10 SSD diskov s kapacitou 960 GB. K dispozícii je vyhradený disk na ukladanie operácií zápisu do vyrovnávacej pamäte a ukladanie virtuálneho stroja služby. Samotné riešenie je štvrtá verzia. Prvý je úprimne hrubý (súdiac podľa recenzií), druhý je vlhký, tretí je už celkom stabilný a toto možno nazvať vydaním po skončení beta testovania pre širokú verejnosť. Počas testovania som nevidel žiadne problémy, všetko funguje ako hodinky.
Zmeny vo verzii 4Bolo opravených veľa chýb.
Spočiatku mohla platforma pracovať iba s hypervízorom VMware ESXi a podporovala malý počet uzlov. Taktiež proces nasadenia sa nie vždy skončil úspešne, niektoré kroky bolo potrebné reštartovať, vyskytli sa problémy s aktualizáciou zo starších verzií, údaje v GUI sa nezobrazovali vždy korektne (aj keď so zobrazovaním grafov výkonnosti stále nie som spokojný ), niekedy sa vyskytli problémy na rozhraní s virtualizáciou.
Teraz sú všetky problémy z detstva opravené, HyperFlex zvládne ESXi aj Hyper-V a navyše je možné:
- Vytvorenie natiahnutého klastra.
- Vytvorenie klastra pre kancelárie bez použitia Fabric Interconnect, od dvoch do štyroch uzlov (kupujeme iba servery).
- Schopnosť pracovať s externými úložnými systémami.
- Podpora kontajnerov a Kubernetes.
- Vytvorenie zón dostupnosti.
- Integrácia s VMware SRM, ak vstavaná funkčnosť nie je uspokojivá.
Architektúra sa príliš nelíši od riešení jeho hlavných konkurentov, nevytvorili bicykel. Všetko beží na virtualizačnej platforme VMware alebo Hyper-V. Hardvér je umiestnený na proprietárnych serveroch Cisco UCS. Sú takí, ktorí platformu nenávidia pre relatívnu zložitosť prvotného nastavenia, množstvo tlačidiel, netriviálny systém šablón a závislostí, no sú aj takí, ktorí sa naučili zen, inšpiruje ich táto myšlienka a už nechcú pracovať s inými servermi.
Zvážime riešenie pre VMware, pretože riešenie bolo pôvodne vytvorené preň a má viac funkcií; Hyper-V bolo pridané po ceste, aby sme držali krok s konkurenciou a splnili očakávania trhu.
Existuje zhluk serverov plný diskov. K dispozícii sú disky na ukladanie dát (SSD alebo HDD - podľa vášho vkusu a potrieb), na cachovanie je jeden SSD disk. Pri zápise dát do datastore sa dáta ukladajú na cachovaciu vrstvu (vyhradený SSD disk a RAM servisného VM). Paralelne sa do uzlov v klastri odosiela blok údajov (počet uzlov závisí od faktora replikácie klastra). Po potvrdení zo všetkých uzlov o úspešnom nahrávaní sa potvrdenie o nahrávaní odošle do hypervízora a následne do VM. Zaznamenané údaje sú deduplikované, komprimované a zapísané na úložné disky na pozadí. Zároveň sa na úložné disky vždy a sekvenčne zapíše veľký blok, čím sa zníži zaťaženie úložných diskov.
Deduplikácia a kompresia sú vždy povolené a nemožno ich vypnúť. Údaje sa čítajú priamo z úložných diskov alebo z vyrovnávacej pamäte RAM. Ak sa použije hybridná konfigurácia, čítania sa tiež uložia do vyrovnávacej pamäte na SSD.
Dáta nie sú viazané na aktuálnu polohu virtuálneho stroja a sú rozdelené rovnomerne medzi uzly. Tento prístup vám umožňuje rovnomerne zaťažiť všetky disky a sieťové rozhrania. Je tu zjavná nevýhoda: nemôžeme čo najviac znížiť latenciu čítania, keďže neexistuje žiadna záruka lokálnej dostupnosti údajov. Verím však, že v porovnaní so získanými výhodami je to menšia obeť. Navyše oneskorenia siete dosiahli také hodnoty, že prakticky neovplyvňujú celkový výsledok.
Za celú logiku prevádzky diskového subsystému je zodpovedný špeciálny servisný radič VM Cisco HyperFlex Data Platform, ktorý je vytvorený na každom storage node. V našej konfigurácii servisného VM bolo pridelených osem vCPU a 72 GB RAM, čo nie je tak málo. Pripomeniem, že samotný hostiteľ má 28 fyzických jadier a 512 GB RAM.
Servisný VM má prístup k fyzickým diskom priamo preposielaním radiča SAS do VM. Komunikácia s hypervízorom prebieha prostredníctvom špeciálneho modulu IOVisor, ktorý zachytáva I/O operácie a pomocou agenta, ktorý umožňuje odosielať príkazy do API hypervízora. Agent je zodpovedný za prácu so snímkami a klonmi HyperFlex.
Diskové prostriedky sú pripojené k hypervízoru ako zdieľania NFS alebo SMB (v závislosti od typu hypervízora hádajte, ktorý je kde). A pod kapotou je to distribuovaný súborový systém, ktorý vám umožňuje pridať funkcie plnohodnotných úložných systémov pre dospelých: prideľovanie tenkých zväzkov, kompresiu a deduplikáciu, snímky pomocou technológie Redirect-on-Write, synchrónnu/asynchrónnu replikáciu.
Servisný VM poskytuje prístup k rozhraniu WEB správy subsystému HyperFlex. Existuje integrácia s vCenter a väčšinu každodenných úloh je možné vykonávať z neho, ale napríklad dátové úložiská je pohodlnejšie vystrihnúť zo samostatnej webovej kamery, ak ste už prešli na rýchle rozhranie HTML5 alebo používate plnohodnotného Flash klienta. s plnou integráciou. Na webovej kamere služby si môžete pozrieť výkon a podrobný stav systému.
V klastri je ďalší typ uzla – výpočtové uzly. Môžu to byť rackové alebo blade servery bez vstavaných diskov. Tieto servery môžu prevádzkovať virtuálne počítače, ktorých údaje sú uložené na serveroch s diskami. Z hľadiska prístupu k údajom nie je rozdiel medzi typmi uzlov, pretože architektúra zahŕňa abstrakciu od fyzického umiestnenia údajov. Maximálny pomer výpočtových uzlov k uzlom úložiska je 2:1.
Používanie výpočtových uzlov zvyšuje flexibilitu pri škálovaní zdrojov klastra: nemusíme kupovať ďalšie uzly s diskami, ak potrebujeme iba CPU/RAM. Okrem toho môžeme pridať blade klietku a ušetriť tak na umiestnení serverov do racku.
Výsledkom je hyperkonvergovaná platforma s nasledujúcimi funkciami:
- Až 64 uzlov v klastri (až 32 úložných uzlov).
- Minimálny počet uzlov v klastri sú tri (dva pre klaster Edge).
- Mechanizmus redundancie údajov: zrkadlenie s replikačným faktorom 2 a 3.
- Klaster metra.
- Asynchrónna replikácia VM do iného klastra HyperFlex.
- Organizácia prepínania VM do vzdialeného dátového centra.
- Natívne snímky využívajúce technológiu Redirect-on-Write.
- Až 1 PB využiteľného priestoru pri replikačnom faktore 3 a bez deduplikácie. Neberieme do úvahy replikačný faktor 2, pretože to nie je možnosť pre seriózny predaj.
Ďalším obrovským plusom je jednoduchá správa a nasadenie. O všetky zložitosti nastavenia serverov UCS sa postará špecializovaný VM pripravený inžiniermi Cisco.
Konfigurácia skúšobnej stolice:
- 2 x Cisco UCS Fabric Interconnect 6248UP ako riadiaci klaster a sieťové komponenty (48 portov pracujúcich v režime Ethernet 10G/FC 16G).
- Štyri servery Cisco UCS HXAF240 M4.
Vlastnosti servera:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
sieť
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G ethernetové porty
Úložný priestor HBA
Cisco 12G Modular SAS Pass through Controller
Úložné disky
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Viac možností konfigurácieOkrem vybratého hardvéru sú momentálne k dispozícii nasledujúce možnosti:
- HXAF240c M5.
- Jeden alebo dva procesory od Intel Silver 4110 po Intel Platinum I8260Y. K dispozícii druhá generácia.
- 24 pamäťových slotov, pásy od 16 GB RDIMM 2600 do 128 GB LRDIMM 2933.
- Od 6 do 23 dátových diskov, jeden cachovací disk, jeden systémový disk a jeden bootovací disk.
Kapacitné disky
- HX-SD960G61X-EV 960 GB 2.5-palcový podniková hodnota 6G SATA SSD (1x výdrž) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 palca Enterprise Value 6G SATA SSD (1x výdrž) SAS 3.8 TB.
- Ukladanie diskov do vyrovnávacej pamäte
- HX-NVMEXPB-I375 375 GB 2.5-palcový Intel Optane Drive, extrémny výkon a odolnosť.
- HX-NVMEHW-H1600* 1.6 TB 2.5-palcový Ent. Perf. NVMe SSD (3X výdrž) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5-palcový Ent. Perf. 12G SAS SSD (10X výdrž) SAS 400 GB.
- HX-SD800GBENK9** 800 GB 2.5-palcový Ent. Perf. 12G SAS SED SSD (10X výdrž) SAS 800 GB.
- HX-SD16T123X-EP 1.6 TB 2.5 palca Enterprise performance 12G SAS SSD (3x výdrž).
Systémové/logové jednotky
- HX-SD240GM1X-EV 240 GB 2.5-palcový Enterprise Value 6G SATA SSD (Vyžaduje upgrade).
Spúšťacie jednotky
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Pripojte sa k sieti cez ethernetové porty 40G, 25G alebo 10G.
FI môže byť HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Samotný test
Na testovanie diskového subsystému som použil HCIBench 2.2.1. Toto je bezplatný nástroj, ktorý vám umožňuje automatizovať vytváranie záťaže z viacerých virtuálnych strojov. Samotné zaťaženie je generované obvyklým fio.
Náš klaster pozostáva zo štyroch uzlov, replikačný faktor 3, všetky disky sú Flash.
Na testovanie som vytvoril štyri dátové úložiská a osem virtuálnych strojov. Pri testoch zápisu sa predpokladá, že disk vyrovnávacej pamäte nie je plný.
Výsledky testu sú nasledovné:
100 % prečítané 100 % náhodné
0 % Čítanie 100 % Náhodné
Hĺbka bloku / frontu
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
Tučné písmo označuje hodnoty, po ktorých nedochádza k zvýšeniu produktivity, niekedy je dokonca viditeľná degradácia. Je to spôsobené tým, že sme limitovaní výkonom siete/radičov/diskov.
- Sekvenčné čítanie 4432 MB/s.
- Sekvenčný zápis 804 MB/s.
- Ak jeden radič zlyhá (zlyhanie virtuálneho počítača alebo hostiteľa), pokles výkonu je dvojnásobný.
- Ak zlyhá úložný disk, pokles je 1/3. Obnova disku zaberá 5 % zdrojov každého radiča.
Na malom bloku sme limitovaní výkonom radiča (virtuálneho stroja), jeho CPU je zaťažené na 100% a pri zvýšení bloku sme limitovaní šírkou pásma portu. 10 Gbps nestačí na odomknutie potenciálu systému AllFlash. Bohužiaľ, parametre poskytnutého demo stojanu nám neumožňujú otestovať prevádzku na 40 Gbit/s.
Podľa môjho dojmu z testov a štúdia architektúry, vďaka algoritmu, ktorý umiestňuje dáta medzi všetkých hostiteľov, dostávame škálovateľný, predvídateľný výkon, ale to je aj obmedzenie pri čítaní, pretože by bolo možné vytlačiť viac z lokálnych diskov, tu môže ušetriť produktívnejšiu sieť, napríklad je k dispozícii FI s rýchlosťou 40 Gbit/s.
Obmedzením môže byť aj jeden disk pre cachovanie a deduplikáciu, v tomto testbede totiž môžeme zapisovať na štyri SSD disky. Bolo by skvelé, keby sme mohli zvýšiť počet jednotiek ukladania do vyrovnávacej pamäte a vidieť rozdiel.
Skutočné využitie
Na usporiadanie zálohovacieho dátového centra môžete použiť dva prístupy (neuvažujeme o umiestnení zálohy na vzdialenú lokalitu):
- Aktívny pasívny. Všetky aplikácie sú hosťované v hlavnom dátovom centre. Replikácia je synchrónna alebo asynchrónna. Ak zlyhá hlavné dátové centrum, musíme aktivovať záložné. Toto je možné vykonať manuálne/skripty/orchestračné aplikácie. Tu dostaneme RPO úmerné frekvencii replikácie a RTO závisí od reakcie a schopností administrátora a kvality vývoja/ladenia plánu prepínania.
- Aktívne-Aktívne. V tomto prípade ide len o synchrónnu replikáciu, dostupnosť dátových centier určuje kvórum/arbiter, ktorý sa nachádza výlučne na treťom mieste. RPO = 0 a RTO môže dosiahnuť 0 (ak to aplikácia umožňuje) alebo sa rovná času prepnutia uzla vo virtualizačnom klastri. Na úrovni virtualizácie sa vytvorí natiahnutý (Metro) klaster, ktorý vyžaduje aktívne-aktívne úložisko.
Väčšinou vidíme, že klienti už majú v hlavnom dátovom centre implementovanú architektúru s klasickým úložným systémom, preto navrhujeme ďalšiu na replikáciu. Ako som už spomenul, Cisco HyperFlex ponúka asynchrónnu replikáciu a vytváranie roztiahnutých virtualizačných klastrov. Zároveň nepotrebujeme dedikovaný úložný systém úrovne Midrange a vyššej s drahými replikačnými funkciami a Active-Active prístupom k dátam na dvoch úložných systémoch.
Scenár 1: Máme primárne a záložné dátové centrá, virtualizačnú platformu na VMware vSphere. Všetky produktívne systémy sú umiestnené v hlavnom dátovom centre a replikácia virtuálnych strojov sa vykonáva na úrovni hypervízora, čím sa zabráni tomu, aby boli VM zapnuté v záložnom dátovom centre. Replikujeme databázy a špeciálne aplikácie pomocou vstavaných nástrojov a udržiavame VM zapnuté. Ak zlyhá hlavné dátové centrum, spustíme systémy v záložnom dátovom centre. Veríme, že máme okolo 100 virtuálnych strojov. Kým je primárne dátové centrum v prevádzke, v pohotovostnom dátovom centre môžu byť spustené testovacie prostredia a iné systémy, ktoré možno vypnúť, ak sa primárne dátové centrum prepne. Je tiež možné, že použijeme obojsmernú replikáciu. Z hardvérového hľadiska sa nič nezmení.
V prípade klasickej architektúry nainštalujeme do každého dátového centra hybridný úložný systém s prístupom cez FibreChannel, vrstvením, deduplikáciou a kompresiou (nie však online), 8 servermi pre každú lokalitu, 2 prepínačmi FibreChannel a 10G Ethernet. Na správu replikácie a prepínania v klasickej architektúre môžeme použiť nástroje VMware (Replication + SRM) alebo nástroje tretích strán, ktoré budú o niečo lacnejšie a niekedy aj pohodlnejšie.
Obrázok ukazuje diagram.
Pri použití Cisco HyperFlex sa získa nasledujúca architektúra:
Pre HyperFlex som použil servery s veľkými zdrojmi CPU/RAM, pretože... Časť prostriedkov pôjde do VM radiča HyperFlex, z hľadiska CPU a pamäte som dokonca trochu prekonfiguroval konfiguráciu HyperFlex, aby som sa nehral so spoločnosťou Cisco a zaručil zdroje pre zostávajúce VM. Môžeme však opustiť prepínače FibreChannel a nebudeme potrebovať ethernetové porty pre každý server, lokálna prevádzka sa prepína v rámci FI.
Výsledkom bola nasledujúca konfigurácia pre každé dátové centrum:
Servery
8 x 1U server (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
Hybridný úložný systém s FC Front-End (20 TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet switch 10G 12 portov
-
SAN
2 x FC prepínač 32/16Gb 24 portov
2 x Cisco UCS FI 6332
Licencie
VMware Ent Plus
Replikácia a/alebo orchestrácia prepínania VM
VMware Ent Plus
Neposkytol som licencie na replikačný softvér pre Hyperflex, pretože je pre nás k dispozícii hneď po vybalení.
Pre klasickú architektúru som si vybral predajcu, ktorý sa etabloval ako kvalitný a lacný výrobca. Pri oboch možnostiach som uplatnil štandardnú zľavu na konkrétne riešenie a vďaka tomu som dostal reálne ceny.
Riešenie Cisco HyperFlex vyšlo o 13 % lacnejšie.
Scenár 2: vytvorenie dvoch aktívnych dátových centier. V tomto scenári navrhujeme natiahnutý klaster na VMware.
Klasická architektúra pozostáva z virtualizačných serverov, SAN (FC protokol) a dvoch úložných systémov, ktoré dokážu čítať a zapisovať na zväzok natiahnutý medzi nimi. Na každý úložný systém vložíme užitočnú kapacitu na skladovanie.
V HyperFlex jednoducho vytvoríme Stretch Cluster s rovnakým počtom uzlov na oboch lokalitách. V tomto prípade sa použije replikačný faktor 2+2.
Výsledkom je nasledujúca konfigurácia:
klasickej architektúry
HyperFlex
Servery
16 x 1U server (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 úložný systém AllFlash (150 TB SSD)
-
LAN
4 x Ethernet switch 10G 24 portov
-
SAN
4 x FC prepínač 32/16Gb 24 portov
4 x Cisco UCS FI 6332
Licencie
VMware Ent Plus
VMware Ent Plus
Pri všetkých výpočtoch som nebral do úvahy sieťovú infraštruktúru, náklady dátového centra atď.: tie budú rovnaké pre klasickú architektúru aj pre riešenie HyperFlex.
Pokiaľ ide o náklady, HyperFlex sa ukázal byť o 5% drahší. Tu stojí za zmienku, že pokiaľ ide o zdroje CPU / RAM, mal som pre Cisco odchýlku, pretože v konfigurácii som kanály radiča pamäte naplnil rovnomerne. Náklady sú o niečo vyššie, ale nie rádovo, čo jasne naznačuje, že hyperkonvergencia nie je nevyhnutne „hračka pre bohatých“, ale môže konkurovať štandardnému prístupu k budovaniu dátového centra. To môže byť zaujímavé aj pre tých, ktorí už majú servery Cisco UCS a zodpovedajúcu infraštruktúru pre ne.
Medzi výhody patrí absencia nákladov na správu SAN a úložných systémov, online kompresia a deduplikácia, jediný vstupný bod pre podporu (virtualizácia, servery, sú to aj úložné systémy), úspora miesta (nie však vo všetkých scenároch), zjednodušenie prevádzky.
Čo sa týka podpory, tu ju máte od jedného predajcu – Cisco. Podľa mojich skúseností so servermi Cisco UCS sa mi to páči; nemusel som to otvárať na HyperFlex, všetko fungovalo rovnako. Inžinieri reagujú promptne a dokážu vyriešiť nielen typické problémy, ale aj zložité okrajové prípady. Niekedy sa na nich obraciam s otázkami: „Dá sa to urobiť, priskrutkujte to?“ alebo „Niečo som tu nakonfiguroval a nechce to fungovať. Pomoc!" - trpezlivo tam nájdu potrebného sprievodcu a upozornia na správne úkony, neodpovedia: "Riešime len hardvérové problémy."
referencie
- Môj mail - [chránené e-mailom]
Zdroj: hab.com