Ovo je mit koji je prilično čest u polju poslužiteljskog hardvera. U praksi su hiperkonvergirana rješenja (kada je sve u jednom) potrebna za mnoge stvari. Povijesno gledano, prve arhitekture razvili su Amazon i Google za svoje usluge. Tada je ideja bila napraviti računalnu farmu od identičnih čvorova od kojih je svaki imao svoje diskove. Sve je to bilo objedinjeno nekim softverom za formiranje sustava (hipervizor) i podijeljeno na virtualne strojeve. Glavni cilj je minimum napora za servisiranje jednog čvora i minimum problema pri skaliranju: samo kupite još tisuću ili dvije istih servera i povežite ih u blizini. U praksi su to izolirani slučajevi, a mnogo češće je riječ o manjem broju čvorova i nešto drugačijoj arhitekturi.
Ali plus ostaje isti - nevjerojatna jednostavnost skaliranja i upravljanja. Loša strana je što različiti zadaci različito troše resurse, a na nekim će mjestima biti puno lokalnih diskova, na drugima će biti malo RAM-a i tako dalje, odnosno za različite vrste zadataka smanjit će se iskoristivost resursa.
Ispada da plaćate 10–15% više za jednostavno postavljanje. To je ono što je pokrenulo mit iz naslova. Dugo smo tražili gdje bi se tehnologija optimalno primijenila i našli smo je. Činjenica je da Cisco nije imao svoje sustave za pohranu podataka, već je želio kompletno tržište poslužitelja. I napravili su Cisco Hyperflex - rješenje s lokalnom pohranom na čvorovima.
I to se odjednom pokazalo kao jako dobro rješenje za rezervne podatkovne centre (Disaster Recovery). Sada ću vam reći zašto i kako. I pokazat ću vam testove klastera.
Gdje je potrebno
Hiperkonvergencija je:
- Prijenos diskova u računalne čvorove.
- Potpuna integracija podsustava za pohranu podataka s podsustavom za virtualizaciju.
- Prijenos/integracija s mrežnim podsustavom.
Ova kombinacija vam omogućuje implementaciju mnogih značajki sustava za pohranu na razini virtualizacije i sve iz jednog kontrolnog prozora.
U našoj su tvrtki projekti dizajniranja redundantnih podatkovnih centara vrlo traženi, a hiperkonvergirano rješenje često se odabire zbog hrpe opcija replikacije (do metroklastera) odmah po završetku.
U slučaju rezervnih podatkovnih centara, obično govorimo o udaljenom objektu na drugom kraju grada ili u drugom gradu. Omogućuje vraćanje kritičnih sustava u slučaju djelomičnog ili potpunog kvara glavnog podatkovnog centra. Tamo se stalno repliciraju podaci o prodaji, a ta replikacija može biti na razini aplikacije ili na razini blok uređaja (pohrane).
Stoga ću sada govoriti o dizajnu sustava i testovima, a zatim o nekoliko scenarija stvarnih aplikacija s podacima o uštedama.
testovi
Naša se instanca sastoji od četiri poslužitelja od kojih svaki ima 10 SSD diskova od 960 GB. Postoji namjenski disk za predmemoriranje operacija pisanja i pohranjivanje servisnog virtualnog stroja. Samo rješenje je četvrta verzija. Prvi je iskreno sirov (sudeći po recenzijama), drugi je vlažan, treći je već prilično stabilan, a ovaj se može nazvati izdanjem nakon završetka beta testiranja za širu javnost. Tijekom testiranja nisam vidio nikakvih problema, sve radi kao sat.
Promjene u v4Ispravljena je hrpa grešaka.
U početku je platforma mogla raditi samo s VMware ESXi hipervizorom i podržavala je mali broj čvorova. Također, proces implementacije nije uvijek uspješno završio, neke korake je trebalo ponovno pokrenuti, bilo je problema s ažuriranjem sa starijih verzija, podaci u GUI-ju nisu uvijek ispravno prikazani (iako još uvijek nisam zadovoljan prikazom grafikona performansi ), ponekad su se problemi javljali na sučelju s virtualizacijom.
Sada su svi problemi iz djetinjstva riješeni, HyperFlex može podnijeti i ESXi i Hyper-V, plus moguće je:
- Stvaranje rastegnutog klastera.
- Izrada klastera za urede bez korištenja Fabric Interconnecta, od dva do četiri čvora (kupujemo samo servere).
- Sposobnost rada s vanjskim sustavima za pohranu podataka.
- Podrška za kontejnere i Kubernetes.
- Stvaranje zona dostupnosti.
- Integracija s VMware SRM ako ugrađena funkcionalnost nije zadovoljavajuća.
Arhitektura se ne razlikuje mnogo od rješenja svojih glavnih konkurenata, oni nisu stvorili bicikl. Sve radi na virtualizacijskoj platformi VMware ili Hyper-V. Hardver se nalazi na vlasničkim Cisco UCS poslužiteljima. Postoje oni koji mrze platformu zbog relativne složenosti početnog postavljanja, puno gumba, netrivijalnog sustava predložaka i ovisnosti, ali postoje i oni koji su naučili Zen, nadahnuti su idejom i više ne žele za rad s drugim poslužiteljima.
Razmotrit ćemo rješenje za VMware, budući da je rješenje izvorno stvoreno za njega i ima više funkcionalnosti, Hyper-V je dodan usput kako bi držali korak s konkurencijom i ispunili očekivanja tržišta.
Postoji klaster poslužitelja punih diskova. Postoje diskovi za pohranu podataka (SSD ili HDD - prema ukusu i potrebama), postoji jedan SSD disk za caching. Prilikom pisanja podataka u pohranu podataka, podaci se spremaju na sloj predmemorije (namjenski SSD disk i RAM servisnog VM-a). Paralelno se blok podataka šalje čvorovima u klasteru (broj čvorova ovisi o faktoru replikacije klastera). Nakon potvrde svih čvorova o uspješnom snimanju, potvrda o snimanju se šalje hipervizoru, a zatim VM-u. Snimljeni podaci se dedupliciraju, komprimiraju i zapisuju na diskove za pohranu u pozadini. U isto vrijeme, veliki blok se uvijek zapisuje na diskove za pohranu i sekvencijalno, što smanjuje opterećenje diskova za pohranu.
Deduplikacija i kompresija uvijek su omogućeni i ne mogu se onemogućiti. Podaci se čitaju izravno s diskova za pohranu ili iz RAM predmemorije. Ako se koristi hibridna konfiguracija, očitanja se također pohranjuju u predmemoriju na SSD-u.
Podaci nisu vezani uz trenutnu lokaciju virtualnog stroja i ravnomjerno su raspoređeni između čvorova. Ovaj vam pristup omogućuje jednako opterećenje svih diskova i mrežnih sučelja. Postoji očiti nedostatak: ne možemo smanjiti latenciju čitanja što je više moguće, budući da ne postoji jamstvo lokalne dostupnosti podataka. Ali vjerujem da je to mala žrtva u usporedbi s dobivenim koristima. Štoviše, mrežna kašnjenja dosegla su takve vrijednosti da praktički ne utječu na ukupni rezultat.
Za cjelokupnu logiku rada diskovnog podsustava odgovoran je poseban servisni kontroler VM Cisco HyperFlex Data Platform, koji se kreira na svakom čvoru za pohranu. U našoj servisnoj VM konfiguraciji dodijeljeno je osam vCPU-a i 72 GB RAM-a, što i nije tako malo. Podsjećam da sam host ima 28 fizičkih jezgri i 512 GB RAM-a.
Servisni VM ima pristup fizičkim diskovima izravno prosljeđujući SAS kontroler VM-u. Komunikacija s hipervizorom odvija se putem posebnog modula IOVisor, koji presreće I/O operacije i pomoću agenta koji vam omogućuje slanje naredbi API-ju hipervizora. Agent je odgovoran za rad s HyperFlex snimkama i klonovima.
Resursi diska montirani su u hipervizor kao NFS ili SMB dijeljenja (ovisno o vrsti hipervizora, pogodite koji je gdje). A ispod haube, ovo je distribuirani datotečni sustav koji vam omogućuje dodavanje značajki punopravnih sustava za pohranu za odrasle: tanka dodjela volumena, kompresija i deduplikacija, snimke pomoću tehnologije Redirect-on-Write, sinkrona/asinkrona replikacija.
Servisni VM omogućuje pristup WEB upravljačkom sučelju podsustava HyperFlex. Postoji integracija s vCentrom i većina svakodnevnih zadataka može se obavljati iz njega, ali pohranu podataka, na primjer, prikladnije je izrezati iz zasebne web kamere ako ste već prešli na brzo HTML5 sučelje ili koristite punopravni Flash klijent uz punu integraciju. U servisnoj web kameri možete vidjeti performanse i detaljan status sustava.
Postoji još jedna vrsta čvorova u klasteru - računalni čvorovi. To mogu biti rack ili blade poslužitelji bez ugrađenih diskova. Ovi poslužitelji mogu pokretati VM-ove čiji su podaci pohranjeni na poslužiteljima s diskovima. Sa stajališta pristupa podacima, nema razlike između vrsta čvorova, jer arhitektura uključuje apstrakciju od fizičke lokacije podataka. Maksimalni omjer računalnih čvorova prema čvorovima za pohranu je 2:1.
Korištenje računalnih čvorova povećava fleksibilnost pri skaliranju resursa klastera: ne moramo kupovati dodatne čvorove s diskovima ako nam je potreban samo CPU/RAM. Osim toga, možemo dodati blade kavez i uštedjeti na postavljanju poslužitelja u stalak.
Kao rezultat toga, imamo hiperkonvergiranu platformu sa sljedećim značajkama:
- Do 64 čvora u klasteru (do 32 čvora za pohranu).
- Najmanji broj čvorova u klasteru je tri (dva za Edge klaster).
- Mehanizam redundantnosti podataka: zrcaljenje s faktorom replikacije 2 i 3.
- Metro klaster.
- Asinkrona VM replikacija na drugi HyperFlex klaster.
- Orkestracija prebacivanja VM-ova na udaljeni podatkovni centar.
- Izvorne snimke pomoću tehnologije Redirect-on-Write.
- Do 1 PB korisnog prostora pri replikacijskom faktoru 3 i bez deduplikacije. Ne uzimamo u obzir replikacijski faktor 2, jer to nije opcija za ozbiljnu prodaju.
Još jedan veliki plus je lakoća upravljanja i implementacije. O svim složenostima postavljanja UCS poslužitelja brine se specijalizirani VM koji su pripremili Ciscovi inženjeri.
Konfiguracija ispitnog stola:
- 2 x Cisco UCS Fabric Interconnect 6248UP kao upravljački klaster i mrežne komponente (48 portova koji rade u Ethernet 10G/FC 16G načinu rada).
- Četiri Cisco UCS HXAF240 M4 poslužitelja.
Karakteristike poslužitelja:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
mreža
UCSC-MLOM-CSC-02 (VIC 1227). 2 10G Ethernet priključka
HBA za pohranu
Cisco 12G modularni SAS prolazni kontroler
Diskovi za pohranu
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Više opcija konfiguracijeUz odabrani hardver trenutno su dostupne sljedeće opcije:
- HXAF240c M5.
- Jedan ili dva CPU-a u rasponu od Intel Silver 4110 do Intel Platinum I8260Y. Dostupna druga generacija.
- 24 memorijska utora, trake od 16 GB RDIMM 2600 do 128 GB LRDIMM 2933.
- Od 6 do 23 diska s podacima, jedan disk za predmemoriju, jedan sistemski disk i jedan boot disk.
Pogoni kapaciteta
- HX-SD960G61X-EV 960GB 2.5 inča Enterprise Value 6G SATA SSD (1X izdržljivost) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 inča Enterprise Value 6G SATA SSD (1X izdržljivost) SAS 3.8 TB.
- Pogoni za predmemoriju
- HX-NVMEXPB-I375 375 GB 2.5 inčni Intel Optane pogon, ekstremne performanse i izdržljivost.
- HX-NVMEHW-H1600* 1.6 TB 2.5 inča Ent. Perf. NVMe SSD (3x izdržljivost) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5 inča Ent. Perf. 12G SAS SSD (10X izdržljivost) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 inča Ent. Perf. 12G SAS SED SSD (10X izdržljivost) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 inča Enterprise performanse 12G SAS SSD (3X izdržljivost).
Pogoni sustava/dnevnika
- HX-SD240GM1X-EV 240GB 2.5 inča Enterprise Value 6G SATA SSD (Zahtijeva nadogradnju).
Pogoni za pokretanje
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Povežite se s mrežom putem 40G, 25G ili 10G Ethernet priključaka.
FI može biti HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Sam test
Za testiranje diskovnog podsustava koristio sam HCIBench 2.2.1. Ovo je besplatni uslužni program koji vam omogućuje automatiziranje stvaranja učitavanja s više virtualnih strojeva. Samo opterećenje generira uobičajeni fio.
Naš klaster se sastoji od četiri čvora, faktor replikacije 3, svi diskovi su Flash.
Za testiranje sam kreirao četiri skladišta podataka i osam virtualnih strojeva. Za testove pisanja, pretpostavlja se da disk za predmemoriju nije pun.
Rezultati ispitivanja su sljedeći:
100% čitanje 100% nasumično
0% pročitano 100% slučajno
Dubina bloka/reda čekanja
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
Podebljano označava vrijednosti nakon kojih nema povećanja produktivnosti, ponekad je čak vidljiva degradacija. To je zbog činjenice da smo ograničeni performansama mreže/kontrolera/diskova.
- Sekvencijalno čitanje 4432 MB/s.
- Sekvencijalno pisanje 804 MB/s.
- Ako jedan kontroler zakaže (kvar virtualnog stroja ili hosta), pad performansi je dvostruk.
- Ako disk za pohranu pokvari, smanjenje je 1/3. Ponovna izgradnja diska uzima 5% resursa svakog kontrolera.
Na malom bloku ograničeni smo performansama kontrolera (virtualnog stroja), njegov CPU je opterećen 100%, a kada se blok povećava, ograničeni smo propusnošću priključka. 10 Gbps nije dovoljno za otključavanje potencijala AllFlash sustava. Nažalost, parametri dostavljenog demo postolja ne dopuštaju nam testiranje rada pri 40 Gbit/s.
Po mom dojmu iz testova i proučavanja arhitekture, zbog algoritma koji postavlja podatke između svih hostova, dobivamo skalabilne, predvidljive performanse, ali to je i ograničenje pri čitanju, jer bi se dalo više istisnuti s lokalnih diskova, ovdje može spasiti produktivniju mrežu, na primjer, dostupan je FI na 40 Gbit/s.
Također, jedan disk za predmemoriju i deduplikaciju može biti ograničenje; zapravo, u ovom testnom postolju možemo pisati na četiri SSD diska. Bilo bi sjajno povećati broj pogona za predmemoriju i vidjeti razliku.
Prava upotreba
Da biste organizirali pričuvni podatkovni centar, možete koristiti dva pristupa (ne razmatramo postavljanje sigurnosne kopije na udaljeno mjesto):
- Aktivno pasivno. Sve aplikacije nalaze se u glavnom podatkovnom centru. Replikacija je sinkrona ili asinkrona. Ako glavni podatkovni centar zakaže, moramo aktivirati rezervni. To se može učiniti ručno/skriptama/aplikacijama za orkestraciju. Ovdje ćemo dobiti RPO razmjeran učestalosti replikacije, a RTO ovisi o reakciji i vještinama administratora te kvaliteti izrade/debugiranja plana prebacivanja.
- Aktivan-Aktivan. U ovom slučaju postoji samo sinkrona replikacija; dostupnost podatkovnih centara određuje kvorum/arbitar koji se nalazi strogo na trećem mjestu. RPO = 0, a RTO može doseći 0 (ako to aplikacija dopušta) ili jednako vremenu prestanka rada čvora u virtualizacijskom klasteru. Na razini virtualizacije stvara se rastegnuti (Metro) klaster koji zahtijeva Active-Active pohranu.
Obično vidimo da su klijenti već implementirali arhitekturu s klasičnim sustavom pohrane u glavnom podatkovnom centru, pa dizajniramo još jedan za replikaciju. Kao što sam spomenuo, Cisco HyperFlex nudi asinkronu replikaciju i stvaranje proširenog virtualizacijskog klastera. U isto vrijeme, ne trebamo namjenski sustav za pohranu srednje razine i više sa skupim replikacijskim funkcijama i Active-Active pristupom podacima na dva sustava za pohranu.
Scenarij 1: Imamo primarni i rezervni podatkovni centar, virtualizacijsku platformu na VMware vSphere. Svi produktivni sustavi nalaze se u glavnom podatkovnom centru, a replikacija virtualnih strojeva izvodi se na razini hipervizora, čime će se izbjeći držanje VM-a uključenim u rezervnom podatkovnom centru. Repliciramo baze podataka i posebne aplikacije pomoću ugrađenih alata i držimo VM uključenima. Ako glavni podatkovni centar zakaže, pokrećemo sustave u rezervnom podatkovnom centru. Vjerujemo da imamo oko 100 virtualnih strojeva. Dok je primarni podatkovni centar operativan, rezervni podatkovni centar može pokrenuti testna okruženja i druge sustave koji se mogu isključiti ako se primarni podatkovni centar prebaci. Također je moguće da koristimo dvosmjernu replikaciju. Sa stajališta hardvera, ništa se neće promijeniti.
U slučaju klasične arhitekture, u svakom podatkovnom centru ćemo instalirati hibridni sustav za pohranu podataka s pristupom putem FibreChannela, tieringom, deduplikacijom i kompresijom (ali ne online), 8 poslužitelja za svaku stranicu, 2 FibreChannel preklopnika i 10G Ethernet. Za replikaciju i upravljanje komutacijom u klasičnoj arhitekturi možemo koristiti VMware alate (Replication + SRM) ili alate trećih strana, koji će biti malo jeftiniji, a ponekad i praktičniji.
Slika prikazuje dijagram.
Kada koristite Cisco HyperFlex, dobiva se sljedeća arhitektura:
Za HyperFlex sam koristio poslužitelje s velikim CPU/RAM resursima, jer... Neki od resursa ići će u HyperFlex kontroler VM; što se tiče CPU-a i memorije, čak sam malo rekonfigurirao HyperFlex konfiguraciju kako ne bih igrao s Ciscom i jamčio resurse za preostale VM-ove. Ali možemo napustiti FibreChannel preklopnike i nećemo trebati Ethernet portove za svaki poslužitelj; lokalni promet se prebacuje unutar FI-ja.
Rezultat je bila sljedeća konfiguracija za svaki podatkovni centar:
poslužitelji
8 x 1U poslužitelj (384 GB RAM-a, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB RAM-a, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
SHD
Hibridni sustav za pohranu s FC Front-End (20TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet preklopnik 10G 12 portova
-
SAN
2 x FC switch 32/16Gb 24 porta
2 x Cisco UCS FI 6332
Licence
VMware Ent Plus
Replikacija i/ili orkestracija VM prebacivanja
VMware Ent Plus
Nisam dao licence softvera za replikaciju za Hyperflex, jer nam je on dostupan odmah.
Za klasičnu arhitekturu odabrao sam dobavljača koji se etablirao kao kvalitetan i jeftin proizvođač. Za obje opcije primijenio sam standardni popust za određeno rješenje i kao rezultat dobio realne cijene.
Rješenje Cisco HyperFlex pokazalo se 13% jeftinijim.
Scenarij 2: stvaranje dva aktivna podatkovna centra. U ovom scenariju, dizajniramo rastegnuti klaster na VMware-u.
Klasična arhitektura sastoji se od virtualizacijskih poslužitelja, SAN-a (FC protokol) i dva sustava za pohranu podataka koji mogu čitati i pisati na volumen koji je razapet između njih. Na svaki skladišni sustav stavljamo korisni kapacitet za skladištenje.
U HyperFlexu jednostavno stvaramo Stretch Cluster s istim brojem čvorova na oba mjesta. U ovom slučaju koristi se faktor replikacije 2+2.
Rezultat je sljedeća konfiguracija:
klasična arhitektura
HyperFlex
poslužitelji
16 x 1U poslužitelj (384 GB RAM-a, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)
16 x HX240C-M5L (512 GB RAM-a, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
SHD
2 x AllFlash sustava za pohranu (150 TB SSD)
-
LAN
4 x Ethernet preklopnik 10G 24 portova
-
SAN
4 x FC switch 32/16Gb 24 porta
4 x Cisco UCS FI 6332
Licence
VMware Ent Plus
VMware Ent Plus
U svim izračunima nisam uzeo u obzir mrežnu infrastrukturu, troškove podatkovnog centra itd.: oni će biti isti za klasičnu arhitekturu i za HyperFlex rješenje.
Što se tiče troškova, HyperFlex se pokazao 5% skupljim. Ovdje je vrijedno napomenuti da sam u pogledu CPU/RAM resursa imao zaokret za Cisco, jer sam u konfiguraciji ravnomjerno ispunio kanale memorijskog kontrolera. Trošak je nešto veći, ali ne za red veličine, što jasno ukazuje da hiperkonvergencija nije nužno „igračka za bogate“, već može konkurirati standardnom pristupu izgradnje podatkovnog centra. Ovo također može biti od interesa za one koji već imaju Cisco UCS poslužitelje i odgovarajuću infrastrukturu za njih.
Među prednostima dobivamo odsustvo troškova za administraciju SAN-a i sustava za pohranu, online kompresiju i deduplikaciju, jednu ulaznu točku za podršku (virtualizacija, poslužitelji, oni su također sustavi za pohranu), uštedu prostora (ali ne u svim scenarijima), pojednostavljivanje rada.
Što se podrške tiče, ovdje je dobivate od jednog dobavljača - Cisco. Sudeći po iskustvu s Cisco UCS serverima, sviđa mi se, nisam ga morao otvarati na HyperFlexu, sve je isto radilo. Inženjeri reagiraju brzo i mogu riješiti ne samo tipične probleme, već i složene rubne slučajeve. Ponekad im se obratim s pitanjem: "Je li moguće to učiniti, zajebite?" ili „Konfigurirao sam nešto ovdje i ne želi raditi. Pomozite!" - tamo će strpljivo pronaći potreban vodič i ukazati na ispravne radnje, neće odgovoriti: "Rješavamo samo hardverske probleme."
reference
- moj mail - [e-pošta zaštićena]
Izvor: www.habr.com