Sziasztok Habr olvasók. Ezzel a cikkel egy sorozatot nyitunk meg, amely az általunk kifejlesztett AERODISK VAIR hiperkonvergens rendszerről fog beszélni. Kezdetben mindent el akartunk mondani mindenről az első cikkben, de elég bonyolult a rendszer, így az elefántot részenként fogjuk megenni.
Kezdjük a történetet a rendszer létrejöttének történetével, mélyedjünk el a vAIR alapját képező ARDFS fájlrendszerben, és beszéljünk egy kicsit ennek a megoldásnak az orosz piacon való elhelyezkedéséről is.
A következő cikkekben részletesebben fogunk beszélni a különböző architekturális komponensekről (fürt, hypervisor, load balancer, monitoring rendszer stb.), a konfiguráció folyamatáról, felvetjük a licencelési problémákat, külön bemutatjuk a törésteszteket és természetesen írunk a terheléstesztekről, ill. méretezés. Külön cikket fogunk szentelni a vAIR közösségi verziójának is.
Az Aerodisk a tárolórendszerekről szól? Vagy miért kezdtük el a hiperkonvergenciát?
Kezdetben valahol 2010 körül támadt bennünk az ötlet, hogy létrehozzuk a saját hiperkonvergenciánkat. Abban az időben sem Aerodisk, sem hasonló megoldások (kereskedelmi dobozos hiperkonvergens rendszerek) nem voltak a piacon. Feladatunk a következő volt: egy Ethernet protokollon keresztüli összeköttetéssel egyesített, helyi lemezes szerverkészletből egy bővített tárolót kellett létrehozni, és ott virtuális gépeket és szoftverhálózatot kellett elindítani. Mindezt tárolórendszerek nélkül kellett megvalósítani (mert egyszerűen nem volt pénz a tárolórendszerekre és a hozzá tartozó hardverekre, saját tárolórendszereket pedig még nem találtunk fel).
Sok nyílt forráskódú megoldást kipróbáltunk, és végül megoldottuk ezt a problémát, de a megoldás nagyon összetett és nehezen megismételhető volt. Ráadásul ez a megoldás a „Működik? Ne nyúlj hozzá! Ezért a probléma megoldása után nem fejlesztettük tovább azt az ötletet, hogy munkánk eredményét teljes értékű termékké alakítsuk.
Az eset után eltávolodtunk ettől az elképzeléstől, de továbbra is az volt az érzésünk, hogy ez a probléma teljesen megoldható, és egy ilyen megoldás előnyei több mint nyilvánvalóak. Ezt követően a külföldi cégek HCI termékei csak megerősítették ezt az érzést.
Ezért 2016 közepén visszatértünk ehhez a feladathoz egy teljes értékű termék létrehozásának részeként. Ekkor még nem volt kapcsolatunk a befektetőkkel, ezért saját, nem túl nagy pénzünkért fejlesztői standot kellett vásárolnunk. Miután összegyűjtöttük a használt szervereket és kapcsolókat az Avito-n, hozzáfogtunk az üzlethez.
A fő kiindulási feladat a saját, bár egyszerű, de saját fájlrendszer létrehozása volt, amely automatikusan és egyenletesen el tudja osztani az adatokat virtuális blokkok formájában az n-edik számú klasztercsomóponton, amelyeket Etherneten keresztül összekötnek egymással. Ugyanakkor az FS-nek jól és könnyen skálázhatónak kell lennie, és függetlennek kell lennie a szomszédos rendszerektől, pl. el kell idegeníteni a vAIR-től „csak egy raktár” formájában.
Az első vAIR koncepció
Szándékosan elhagytuk a kész nyílt forráskódú megoldások használatát a feszített tárolás (ceph, gluster, luster és hasonlók) megszervezésére a saját fejlesztésünk érdekében, mivel már nagy projekttapasztalattal rendelkeztünk velük. Természetesen ezek a megoldások önmagukban is kiválóak, és mielőtt az Aerodisken dolgoztunk, több integrációs projektet is megvalósítottunk velük. De egy dolog egy konkrét feladatot végrehajtani egy ügyfél számára, kiképezni a személyzetet, és esetleg megvenni egy nagy gyártó támogatását, és egészen más dolog egy könnyen reprodukálható terméket létrehozni, amelyet különféle feladatokra használhatunk fel, amit mi, mint egy eladó, talán még magunkról sem fogunk tudni. A második cél érdekében a meglévő nyílt forráskódú termékek nem voltak megfelelőek számunkra, ezért úgy döntöttünk, hogy mi magunk hozunk létre egy elosztott fájlrendszert.
Két évvel később több fejlesztő (akik a vAIR-en végzett munkát a klasszikus Engine-tárolórendszeren végzett munkával kombinálták) elértek egy bizonyos eredményt.
2018-ra egy egyszerű fájlrendszert írtunk és kiegészítettük a szükséges hardverrel. A rendszer a különböző szerverekről származó fizikai (helyi) lemezeket belső összekapcsoláson keresztül egy lapos poolba egyesítette és virtuális blokkokra „vágta”, majd a virtuális blokkokból különböző fokú hibatűrőségű blokkeszközöket hoztak létre, amelyeken virtuálisakat hoztak létre. és a KVM hypervisor autókkal hajtották végre.
Nem foglalkoztunk túl sokat a fájlrendszer nevével, és tömören ARDFS-nek neveztük (találd ki, mit jelent)
Jól nézett ki ez a prototípus (persze vizuálisan nem, látványterv még nem volt), teljesítmény és skálázás terén is jó eredményeket mutatott. Az első valódi eredmény után elindítottuk ezt a projektet, egy teljes értékű fejlesztői környezetet és egy külön csapatot szerveztünk, amely csak a vAIR-rel foglalkozott.
Éppen ekkorra érlelődött ki a megoldás általános architektúrája, amely még nem esett át jelentősebb változásokon.
Búvárkodás az ARDFS fájlrendszerben
Az ARDFS a vAIR alapja, amely elosztott, hibatűrő adattárolást biztosít a teljes fürtben. Az ARDFS egyik (de nem egyetlen) megkülönböztető jellemzője, hogy nem használ további dedikált szervereket a metaadatokhoz és a kezeléshez. Ezt eredetileg a megoldás konfigurációjának egyszerűsítésére és a megbízhatóságra tervezték.
Tároló szerkezet
A fürt összes csomópontján belül az ARDFS logikai készletet szervez az összes rendelkezésre álló lemezterületből. Fontos megérteni, hogy a pool még nem adat vagy formázott terület, hanem egyszerűen jelölés, azaz. A fürthöz adva minden olyan csomópont, amelyre telepítve van a vAIR, automatikusan hozzáadódik a megosztott ARDFS-készlethez, és a lemezerőforrások automatikusan megosztásra kerülnek a teljes fürtben (és elérhetővé válnak a jövőbeni adattároláshoz). Ez a megközelítés lehetővé teszi csomópontok hozzáadását és eltávolítását menet közben anélkül, hogy komoly hatással lenne a már futó rendszerre. Azok. a rendszer nagyon egyszerűen méretezhető „téglákban”, szükség esetén csomópontok hozzáadásával vagy eltávolításával a fürtben.
A virtuális lemezek (a virtuális gépek tárolóobjektumai) az ARDFS-készlet tetejére kerülnek, amelyek 4 megabájt méretű virtuális blokkokból épülnek fel. A virtuális lemezek közvetlenül tárolják az adatokat. A hibatűrési séma is be van állítva a virtuális lemez szintjén.
Amint azt már sejtette, a lemezalrendszer hibatűrése érdekében nem a RAID (Független lemezek redundáns tömbje) fogalmát használjuk, hanem a RAIN-t (Független csomópontok redundáns tömbje). Azok. A hibatűrés mérése, automatizálása és kezelése a csomópontok, nem pedig a lemezek alapján történik. A lemezek természetesen egyben tárolóobjektumok is, ezeket is, mint minden mást, figyelnek, minden szokásos műveletet el lehet velük végezni, beleértve a helyi hardveres RAID összeszerelését is, de a fürt kifejezetten csomópontokon működik.
Abban a helyzetben, amikor valóban RAID-et szeretne (például egy olyan forgatókönyv, amely támogatja a kis fürtök többszörös meghibásodását), semmi sem akadályozza meg, hogy helyi RAID-vezérlőket használjon, és ráterjedt tárhelyet és RAIN-architektúrát építsen. Ez a forgatókönyv meglehetősen élő, és mi támogatjuk, ezért a vAIR használatának tipikus forgatókönyveiről szóló cikkben fogunk beszélni róla.
Tárolási hibatűrési sémák
Két hibatűrési séma lehet a vAIR virtuális lemezei számára:
1) Replikációs faktor vagy egyszerűen replikáció – ez a hibatűrési módszer olyan egyszerű, mint egy bot és egy kötél. A szinkron replikáció a csomópontok között 2-es (2 példány fürtönként) vagy 3-as (3 másolat) tényezővel történik. Az RF-2 lehetővé teszi, hogy egy virtuális lemez kibírja a fürt egyik csomópontjának meghibásodását, de a hasznos kötet felét „megeszi”, az RF-3 pedig kibírja a fürt 2 csomópontjának meghibásodását, de fenntartja a fürt 2/3-át. igényeinek megfelelő kötet. Ez a séma nagyon hasonlít a RAID-1-hez, vagyis az RF-2-ben konfigurált virtuális lemez ellenáll a fürt bármely csomópontjának meghibásodásának. Ilyenkor minden rendben lesz az adatokkal és még az I/O sem áll le. Amikor a kiesett csomópont visszatér a szolgáltatásba, megkezdődik az automatikus adat-helyreállítás/szinkronizálás.
Az alábbiakban példák láthatók az RF-2 és RF-3 adatok normál üzemmódban és hibahelyzetben történő elosztására.
Van egy virtuális gépünk 8 MB egyedi (hasznos) adat kapacitással, amely 4 vAIR csomóponton fut. Nyilvánvaló, hogy a valóságban nem valószínű, hogy ilyen kis mennyiség lesz, de az ARDFS működési logikáját tükröző séma esetében ez a példa a legérthetőbb. Az AB 4 MB-os virtuális blokkok, amelyek egyedi virtuális gépadatokat tartalmaznak. Az RF-2 ezekből az A1+A2 és B1+B2 blokkokból két másolatot készít. Ezek a blokkok csomópontok között vannak „elhelyezve”, elkerülve, hogy ugyanazon a csomóponton ugyanazon adatok metszéspontjai legyenek, vagyis az A1 másolat nem ugyanazon a csomóponton található, mint az A2 példány. Ugyanez a B1-vel és B2-vel.
Ha az egyik csomópont meghibásodik (például a 3. számú csomópont, amely a B1 másolatát tartalmazza), ez a másolat automatikusan aktiválódik azon a csomóponton, ahol nincs másolata (azaz a B2 másolata).
Így a virtuális lemez (és ennek megfelelően a virtuális gép) könnyen túlélheti az RF-2 séma egyik csomópontjának meghibásodását.
A replikációs séma, bár egyszerű és megbízható, ugyanazzal a problémával küzd, mint a RAID1 – nincs elég használható terület.
2) A fenti probléma megoldására létezik törlési kódolás vagy törlési kódolás (más néven „redundáns kódolás”, „törlési kódolás” vagy „redundancia kód”). Az EC egy redundancia, amely magas szintű adatelérhetőséget biztosít a replikációhoz képest alacsonyabb lemezterület mellett. Ennek a mechanizmusnak a működési elve hasonló a RAID 5, 6, 6P-hez.
Kódoláskor az EC folyamat egy virtuális blokkot (alapértelmezés szerint 4 MB) több kisebb "adattömbre" oszt fel az EC sémától függően (például egy 2+1 séma minden 4 MB-os blokkot 2 2 MB-os darabra oszt fel). Ezután ez a folyamat „paritásdarabokat” hoz létre az „adatdarabokhoz”, amelyek nem nagyobbak, mint a korábban felosztott részek egyike. Dekódoláskor az EC előállítja a hiányzó darabokat a „túlélő” adatok beolvasásával a teljes klaszteren.
Például egy virtuális lemez 2 + 1 EC sémával, 4 fürtcsomóponton megvalósítva, ugyanúgy könnyen ellenáll a fürt egyik csomópontjának meghibásodásának, mint az RF-2. Ebben az esetben a rezsiköltségek alacsonyabbak lesznek, különösen az RF-2 hasznos kapacitástényezője 2, az EC 2+1 esetében pedig 1,5.
Egyszerűbben leírva, a lényeg az, hogy a virtuális blokkot 2-8 (miért 2-től 8-ig) „darabra” osztjuk fel, és ezekhez a darabokhoz hasonló térfogatú paritás „darabjait” számolják.
Ennek eredményeként az adatok és a paritás egyenletesen oszlanak el a fürt összes csomópontja között. Ugyanakkor a replikációhoz hasonlóan az ARDFS automatikusan elosztja az adatokat a csomópontok között oly módon, hogy megakadályozza, hogy azonos adatok (az adatok másolatai és paritásuk) ugyanazon a csomóponton kerüljenek tárolásra, így elkerülhető az adatvesztés veszélye. arra a tényre, hogy az adatok és a paritásuk hirtelen egy meghibásodott tárolócsomópontra kerülnek.
Alább látható egy példa, ugyanazzal a 8 MB-os virtuális géppel és 4 csomóponttal, de EC 2+1 sémával.
Az A és B blokk két, egyenként 2 MB-os részre van osztva (kettő, mert 2+1), azaz A1+A2 és B1+B2. A replikával ellentétben az A1 nem az A2 másolata, hanem egy virtuális A blokk, két részre osztva, ugyanez a B blokkal is. Összesen két 4 MB-os készletet kapunk, amelyek mindegyike két két MB-os darabot tartalmaz. Ezután mindegyik halmaz esetében a paritást legfeljebb egy darab (azaz 2 MB) térfogattal számítjuk ki, és további + 2 paritást kapunk (AP és BP). Összesen 4×2 adatunk + 2×2 paritásunk van.
Ezután a darabokat a csomópontok között „elhelyezzük”, hogy az adatok ne metsszék egymást a paritásukkal. Azok. A1 és A2 nem ugyanazon a csomóponton lesz, mint az AP.
Egy csomópont (például a harmadik) meghibásodása esetén a kiesett B1 blokk automatikusan visszaáll a BP paritásból, amely a 2. csomóponton van tárolva, és azon a csomóponton aktiválódik, ahol van nincs B-paritás, pl. darab BP. Ebben a példában ez az 1. csomópont
Biztos vagyok benne, hogy az olvasónak van egy kérdése:
„Mindent, amit leírt, már régóta implementálnak mind a versenytársak, mind a nyílt forráskódú megoldásokban. Mi a különbség az EC ARDFS-ben való megvalósítása között?”
És akkor az ARDFS érdekes funkciói lesznek.
Kódolás törlése a rugalmasságra összpontosítva
Kezdetben egy meglehetősen rugalmas EC X+Y sémát adtunk, ahol X egy 2 és 8 közötti számmal, Y pedig egy 1 és 8 közötti számmal, de mindig kisebb vagy egyenlő, mint X. Ez a séma biztosított. a rugalmasság érdekében. Az adatelemek számának (X) növelése, amelyekre a virtuális blokk fel van osztva, lehetővé teszi az általános költségek csökkentését, vagyis a felhasználható terület növelését.
A paritásdarabok (Y) számának növelése növeli a virtuális lemez megbízhatóságát. Minél nagyobb az Y érték, annál több csomópont hibásodhat meg a fürtben. Természetesen a paritás mennyiségének növelése csökkenti a felhasználható kapacitás mennyiségét, de ez árat kell fizetni a megbízhatóságért.
A teljesítmény függése az EC áramköröktől szinte közvetlen: minél több „darab”, annál kisebb a teljesítmény, itt természetesen kiegyensúlyozott szemléletre van szükség.
Ez a megközelítés lehetővé teszi a rendszergazdák számára, hogy maximális rugalmassággal konfigurálják a nyújtott tárolást. Az ARDFS poolon belül bármilyen hibatűrési sémát és azok kombinációit használhatja, ami véleményünk szerint szintén nagyon hasznos.
Az alábbiakban több (nem minden lehetséges) RF és EC sémát összehasonlító táblázat található.
A táblázat azt mutatja, hogy még a „legfrissebb” EC 8+7 kombináció is, amely akár 7 csomópont elvesztését is lehetővé teszi egy fürtben, kevesebb használható területet „eszik” (1,875 versus 2), mint a szabványos replikáció, és 7-szer jobban véd. , ami ezt a védelmi mechanizmust, bár összetettebb, sokkal vonzóbbá teszi olyan helyzetekben, amikor korlátozott lemezterület esetén a maximális megbízhatóság biztosítása szükséges. Ugyanakkor meg kell értenie, hogy minden „plusz” X-hez vagy Y-hez plusz teljesítményt jelent, ezért a megbízhatóság, a megtakarítás és a teljesítmény közötti háromszögben nagyon körültekintően kell választani. Emiatt külön cikket fogunk szentelni a törlési kódok méretezésének.
A fájlrendszer megbízhatósága és autonómiája
Az ARDFS helyileg fut a fürt összes csomópontján, és saját eszközeivel szinkronizálja azokat dedikált Ethernet interfészeken keresztül. A lényeg az, hogy az ARDFS önállóan nem csak az adatokat, hanem a tároláshoz kapcsolódó metaadatokat is szinkronizálja. Miközben az ARDFS-en dolgoztunk, egyidejűleg számos létező megoldást tanulmányoztunk, és azt tapasztaltuk, hogy sokan szinkronizálják a fájlrendszer metaadatait egy külső elosztott DBMS segítségével, amit szintén használunk szinkronizálásra, de csak konfigurációkat, FS metaadatokat nem (erről és más kapcsolódó alrendszerekről a következő cikkben).
Az FS metaadatok külső DBMS-sel történő szinkronizálása természetesen működő megoldás, de akkor az ARDFS-en tárolt adatok konzisztenciája a külső DBMS-től és viselkedésétől függne (és őszintén szólva egy szeszélyes hölgy), ami rossz a véleményünk. Miért? Ha az FS-metaadatok megsérülnek, maguk az FS-adatok is „viszont viszlát”, ezért úgy döntöttünk, hogy egy bonyolultabb, de megbízhatóbb utat választunk.
Az ARDFS metaadat-szinkronizálási alrendszerét mi magunk készítettük, és az a szomszédos alrendszerektől teljesen függetlenül működik. Azok. egyetlen más alrendszer sem ronthatja el az ARDFS adatokat. Véleményünk szerint ez a legmegbízhatóbb és leghelyesebb módszer, de az idő eldönti, hogy valóban így van-e. Ezen túlmenően ennek a megközelítésnek további előnye is van. Az ARDFS a vAIR-től függetlenül is használható, csakúgy, mint a feszített tárolás, amelyet minden bizonnyal a jövőbeni termékekben is alkalmazni fogunk.
Ennek eredményeként az ARDFS fejlesztésével rugalmas és megbízható fájlrendszert kaptunk, amely választási lehetőséget ad, ahol kapacitást takaríthat meg, vagy mindent feladhat a teljesítményről, vagy rendkívül megbízható tárolást készíthet ésszerű költséggel, de csökkenti a teljesítményigényt.
Az egyszerű engedélyezési politikával és a rugalmas szállítási modellel együtt (a jövőre nézve a vAIR-t node licenceli, és szoftverként vagy szoftvercsomagként szállítják) ez lehetővé teszi, hogy a megoldást nagyon precízen a vásárlói igények széles skálájához igazítsa. akkor könnyen fenntarthatja ezt az egyensúlyt.
Kinek kell ez a csoda?
Egyrészt elmondhatjuk, hogy már most is vannak olyan szereplők a piacon, akiknek komoly megoldásai vannak a hiperkonvergencia terén, és tulajdonképpen itt tartunk. Úgy tűnik, ez az állítás igaz, DE...
Másrészt, amikor kimegyünk a terepre és kommunikálunk az ügyfelekkel, mi és partnereink azt látjuk, hogy ez egyáltalán nem így van. A hiperkonvergenciára számos feladat van, néhol egyszerűen nem tudták, hogy léteznek ilyen megoldások, máshol drágának tűnt, máshol sikertelenül tesztelték az alternatív megoldásokat, máshol pedig szankciók miatt egyáltalán tiltják a vásárlást. Általában a mező felszántatlannak bizonyult, ezért elmentünk szűz talajt emelni))).
Mikor jobb a tárolási rendszer, mint a GCS?
Miközben a piaccal dolgozunk, gyakran kérdezik tőlünk, hogy mikor érdemesebb klasszikus sémát használni a tárolórendszerekkel, és mikor a hiperkonvergenst? Sok GCS-t gyártó cég (különösen azok, amelyek nem rendelkeznek tárolórendszerrel a portfóliójukban) azt mondják: „A tárolórendszerek elavulnak, csak hiperkonvergensek!” Ez merész kijelentés, de nem teljesen tükrözi a valóságot.
Valójában a tárolási piac valóban a hiperkonvergencia és hasonló megoldások felé halad, de mindig van egy „de”.
Egyrészt a klasszikus séma szerint, tárolórendszerekkel megépült adatközpontok és informatikai infrastruktúrák nem egyszerűen újraépíthetők, így az ilyen infrastruktúrák korszerűsítése, kiépítése még 5-7 éves örökség.
Másodszor, a jelenleg épülő infrastruktúra nagyrészt (értsd: Orosz Föderáció) a klasszikus séma szerint épül fel tárolórendszerekkel, és nem azért, mert az emberek nem ismerik a hiperkonvergenciát, hanem azért, mert a hiperkonvergencia piaca új, megoldásokat ill. a szabványok még nincsenek kialakítva , az informatikusok még nincsenek kiképezve, kevés tapasztalatuk van, de adatközpontokat kell építeni itt és most. És ez a tendencia még 3-5 évig tart (majd egy újabb örökség, lásd 1. pont).
Harmadszor, pusztán technikai korlátai vannak az írásonkénti 2 ezredmásodperces további kis késéseknek (természetesen a helyi gyorsítótár kivételével), amelyek az elosztott tárolás költségét jelentik.
Nos, ne feledkezzünk meg a nagy fizikai szerverek használatáról sem, amelyek szeretik a lemez alrendszer függőleges skálázását.
Számos szükséges és népszerű feladat van, ahol a tárolórendszerek jobban viselkednek, mint a GCS. Itt természetesen azok a gyártók, akiknek nincs tárolórendszerük a termékportfóliójukban, nem értenek egyet velünk, de készek vagyunk ésszerűen vitatkozni. Természetesen mi, mint mindkét termék fejlesztője, mindenképpen össze fogjuk hasonlítani a tárolórendszereket és a GCS-t valamelyik jövőbeni kiadványunkban, ahol egyértelműen bemutatjuk, melyik milyen feltételek mellett jobb.
És hol működnek jobban a hiperkonvergens megoldások, mint a tárolórendszerek?
A fentiek alapján három nyilvánvaló következtetés vonható le:
- Ahol további 2 ezredmásodperces késleltetés a rögzítéshez, ami minden termékben konzisztensen előfordul (most nem a szintetikáról beszélünk, a szintetikán nanoszekundumokat lehet kimutatni), ott kritikátlan a hiperkonvergens.
- Ahol a nagy fizikai szerverek terhelése sok kis virtuálisra alakítható és csomópontok között osztható el, ott a hiperkonvergencia is jól működik.
- Ahol a vízszintes méretezés magasabb prioritást élvez, mint a függőleges méretezés, a GCS ott is jól működik.
Mik ezek a megoldások?
- Minden szabványos infrastrukturális szolgáltatás (címtárszolgáltatás, levelezés, EDMS, fájlszerverek, kis vagy közepes ERP és BI rendszerek stb.). Ezt nevezzük „általános számítástechnikának”.
- A felhőszolgáltatók infrastruktúrája, ahol gyorsan és szabványosítva kell horizontálisan bővíteni és könnyen „levágni” nagyszámú virtuális gépet az ügyfelek számára.
- Virtuális asztali infrastruktúra (VDI), ahol sok kis felhasználói virtuális gép fut és csendben „lebeg” egy egységes fürtben.
- Fiókhálózatok, ahol minden ágnak szüksége van egy szabványos, hibatűrő, de olcsó, 15-20 virtuális gépből álló infrastruktúrára.
- Bármilyen elosztott számítástechnika (például nagy adatszolgáltatás). Ahol a terhelés nem „mélységben”, hanem „szélességben” megy.
- Tesztkörnyezetek, ahol további kis késések is elfogadhatók, de vannak költségvetési korlátozások, mivel ezek tesztek.
Jelenleg ezekre a feladatokra készítettük el az AERODISK VAIR-t, és ezekre koncentrálunk (eddig sikeresen). Talán ez hamarosan megváltozik, mert... a világ nem áll meg.
Így…
Ezzel befejeződik egy nagy cikksorozat első része, a következő cikkben a megoldás architektúrájáról és a felhasznált komponensekről lesz szó.
Szívesen fogadunk kérdéseket, javaslatokat és építő jellegű vitákat.
Forrás: will.com