Iki minangka mitos sing cukup umum ing babagan hardware server. Ing praktik, solusi hyperconverged (nalika kabeh ana ing siji) dibutuhake kanggo akeh perkara. Secara historis, arsitektur pisanan dikembangake dening Amazon lan Google kanggo layanane. Banjur idea iki kanggo nggawe farm komputasi saka simpul identik, saben kang wis disk dhewe. Kabeh iki digabungake karo sawetara piranti lunak pembentuk sistem (hypervisor) lan dipérang dadi mesin virtual. Sasaran utama yaiku minimal gaweyan kanggo nglayani siji simpul lan minimal masalah nalika skala: mung tuku sewu utawa loro server sing padha lan sambungake ing cedhak. Ing praktik, iki minangka kasus sing terisolasi, lan luwih asring kita ngomong babagan jumlah simpul sing luwih cilik lan arsitektur sing rada beda.
Nanging plus tetep padha - ease luar biasa skala lan manajemen. Kelemahane yaiku tugas sing beda-beda nggunakake sumber daya sing beda-beda, lan ing sawetara panggonan bakal akeh disk lokal, ing liyane bakal ana RAM sing sithik, lan liya-liyane, yaiku, kanggo macem-macem jinis tugas, panggunaan sumber daya bakal mudhun.
Pranyata sampeyan mbayar 10-15% luwih kanggo gampang persiyapan. Iki sing nyebabake mitos ing judhul kasebut. Kita ngenteni suwene nggoleki ing ngendi teknologi kasebut bakal ditrapake kanthi optimal, lan kita nemokake. Kasunyatan iku Cisco ora duwe sistem panyimpenan dhewe, nanging padha pengin pasar server lengkap. Lan padha nggawe Cisco Hyperflex - solusi karo panyimpenan lokal ing kelenjar.
Lan iki dumadakan dadi solusi sing apik kanggo pusat data serep (Disaster Recovery). Aku bakal pitutur marang kowe kok lan carane saiki. Lan aku bakal nuduhake sampeyan tes kluster.
Ing ngendi perlu
Hiperkonvergensi yaiku:
- Nransfer disk kanggo ngitung simpul.
- Integrasi lengkap subsistem panyimpenan karo subsistem virtualisasi.
- Transfer/integrasi karo subsistem jaringan.
Kombinasi iki ngidini sampeyan ngleksanakake akeh fitur sistem panyimpenan ing tingkat virtualisasi lan kabeh saka siji jendhela kontrol.
Ing perusahaan kita, proyek kanggo ngrancang pusat data keluwih akeh dikarepake, lan solusi hyperconverged asring dipilih amarga akeh opsi replikasi (nganti metrocluster) metu saka kothak.
Ing kasus pusat data serep, kita biasane ngomong babagan fasilitas remot ing situs ing sisih liya kutha utawa ing kutha liyane. Iki ngidini sampeyan mulihake sistem kritis yen ana kegagalan sebagian utawa lengkap saka pusat data utama. Data penjualan terus ditiru ing kana, lan replikasi iki bisa ing tingkat aplikasi utawa ing tingkat piranti pamblokiran (panyimpenan).
Mulane, saiki aku bakal ngomong babagan desain sistem lan tes, banjur babagan sawetara skenario aplikasi nyata kanthi data tabungan.
Tes
Kayata kita kasusun saka papat server, saben kang duwe 10 SSD drive saka 960 GB. Ana disk khusus kanggo operasi nulis cache lan nyimpen mesin virtual layanan. Solusi kasebut dhewe yaiku versi kaping papat. Pisanan terus terang mentah (dinilai saka ulasan), sing nomer loro lembab, sing katelu wis cukup stabil, lan iki bisa diarani rilis sawise pungkasan tes beta kanggo masarakat umum. Sajrone tes, aku ora weruh masalah, kabeh kerjane kaya jam.
Owah-owahan ing v4A Bunch saka kewan omo wis didandani.
Kaping pisanan, platform mung bisa digunakake karo hypervisor VMware ESXi lan ndhukung sawetara node. Uga, proses panyebaran ora tansah rampung kanthi sukses, sawetara langkah kudu diwiwiti maneh, ana masalah karo nganyari saka versi lawas, data ing GUI ora tansah ditampilake kanthi bener (sanajan aku isih ora seneng karo tampilan grafik kinerja. ), kadhangkala ana masalah ing antarmuka karo virtualisasi.
Saiki kabeh masalah kanak-kanak wis didandani, HyperFlex bisa nangani loro ESXi lan Hyper-V, plus iku bisa kanggo:
- Nggawe kluster dowo.
- Nggawe kluster kanggo kantor tanpa nggunakake Fabric Interconnect, saka loro nganti patang kelenjar (kita tuku mung server).
- Kemampuan kanggo nggarap sistem panyimpenan eksternal.
- Dhukungan kanggo kontaner lan Kubernetes.
- Nggawe zona kasedhiyan.
- Integrasi karo VMware SRM yen fungsi dibangun ing ora marem.
Arsitèktur ora beda banget karo solusi para pesaing utama, ora nggawe sepeda. Kabeh mlaku ing platform virtualisasi VMware utawa Hyper-V. Hardware wis tuan rumah ing proprietary Cisco UCS server. Ana sing sengit platform kanggo kerumitan relatif saka persiyapan awal, akeh tombol, sistem non-trivial cithakan lan dependensi, nanging ana uga sing wis sinau Zen, inspirasi dening idea lan ora pengin maneh. kanggo nggarap server liyane.
Kita bakal nimbang solusi kanggo VMware, amarga solusi kasebut asline digawe lan duwe fungsi luwih akeh; Hyper-V ditambahake ing sadawane dalan supaya bisa bersaing karo pesaing lan nyukupi pangarepan pasar.
Ana klompok server kebak disk. Ana disk kanggo panyimpenan data (SSD utawa HDD - miturut rasa lan kabutuhan), ana siji disk SSD kanggo caching. Nalika nulis data menyang datastore, data disimpen ing lapisan caching (disk SSD darmabakti lan RAM saka layanan VM). Ing podo karo, blok data dikirim menyang simpul ing kluster (jumlah simpul gumantung saka faktor replikasi kluster). Sawise konfirmasi saka kabeh simpul babagan rekaman sukses, konfirmasi rekaman dikirim menyang hypervisor banjur menyang VM. Data sing direkam deduplikat, dikompres lan ditulis menyang disk panyimpenan ing latar mburi. Ing wektu sing padha, blok gedhe tansah ditulis ing disk panyimpenan lan kanthi urutan, sing nyuda beban ing disk panyimpenan.
Deduplikasi lan kompresi tansah diaktifake lan ora bisa dipateni. Data diwaca langsung saka disk panyimpenan utawa saka cache RAM. Yen konfigurasi Sato digunakake, maca uga cache ing SSD.
Data kasebut ora disambungake menyang lokasi mesin virtual saiki lan disebarake kanthi rata ing antarane kelenjar. Pendekatan iki ngidini sampeyan mbukak kabeh disk lan antarmuka jaringan kanthi padha. Ana kerugian sing jelas: kita ora bisa nyuda latensi maca sabisa, amarga ora ana jaminan kasedhiyan data sacara lokal. Nanging aku percaya yen iki minangka pengorbanan cilik dibandhingake karo keuntungan sing ditampa. Kajaba iku, wektu tundha jaringan wis tekan angka sing meh ora mengaruhi asil sakabèhé.
A layanan khusus VM Cisco HyperFlex Data Platform controller, kang digawe ing saben simpul panyimpenan, tanggung jawab kanggo kabeh logika operasi saka subsistem disk. Ing konfigurasi VM layanan kita, wolung vCPU lan 72 GB RAM dialokasikan, sing ora sithik. Ayo kula ngelingake yen host dhewe duwe 28 inti fisik lan 512 GB RAM.
Layanan VM nduweni akses menyang disk fisik langsung kanthi nerusake pengontrol SAS menyang VM. Komunikasi karo hypervisor dumadi liwat modul khusus IOVisor, kang intercepts I / O operasi, lan nggunakake agen sing ngijini sampeyan kanggo ngirim printah kanggo API hypervisor. Agen tanggung jawab kanggo nggarap gambar lan kloning HyperFlex.
Sumber daya disk dipasang ing hypervisor minangka NFS utawa SMB nuduhake (gumantung saka jinis hypervisor, guess kang ngendi). Lan ing ngisor tudung, iki minangka sistem file sing disebarake sing ngidini sampeyan nambah fitur sistem panyimpenan lengkap diwasa: alokasi volume tipis, kompresi lan deduplikasi, jepretan nggunakake teknologi Redirect-on-Write, replikasi sinkron / asinkron.
Layanan VM nyedhiyakake akses menyang antarmuka manajemen WEB subsistem HyperFlex. Ana integrasi karo vCenter, lan paling tugas saben dina bisa dileksanakake saka iku, nanging datastores, contone, luwih trep kanggo Cut saka webcam kapisah yen sampeyan wis ngalih menyang antarmuka HTML5 cepet, utawa nggunakake klien Flash lengkap. kanthi integrasi lengkap. Ing webcam layanan sampeyan bisa ndeleng kinerja lan status rinci sistem.
Ana jinis simpul liyane ing kluster - simpul komputasi. Iki bisa dadi server rak utawa blade tanpa disk sing dibangun. Server iki bisa mbukak VM sing data disimpen ing server karo disk. Saka sudut pandang akses data, ora ana bedane antarane jinis simpul, amarga arsitektur kalebu abstraksi saka lokasi fisik data. Rasio maksimum simpul komputasi kanggo simpul panyimpenan yaiku 2:1.
Nggunakake simpul komputasi nambah keluwesan nalika skala sumber daya kluster: kita ora kudu tuku kelenjar tambahan karo disk yen kita mung butuh CPU / RAM. Kajaba iku, kita bisa nambah kandhang agul-agul lan nyimpen ing panggonan seko rak saka server.
Akibaté, kita duwe platform hyperconverged kanthi fitur ing ngisor iki:
- Nganti 64 simpul ing kluster (nganti 32 simpul panyimpenan).
- Jumlah minimal simpul ing kluster yaiku telung (loro kanggo kluster Edge).
- Mekanisme redundansi data: mirroring kanthi faktor replikasi 2 lan 3.
- Kluster Metro.
- Replikasi VM Asynchronous menyang cluster HyperFlex liyane.
- Orkestrasi ngoper VM menyang pusat data remot.
- Gambar asli nggunakake teknologi Redirect-on-Write.
- Nganti 1 PB ruang sing bisa digunakake ing faktor replikasi 3 lan tanpa deduplikasi. Kita ora nganggep faktor replikasi 2, amarga iki dudu pilihan kanggo penjualan serius.
Plus gedhe liyane yaiku gampang manajemen lan panyebaran. Kabeh kerumitan nyetel server UCS ditangani dening VM khusus sing disiapake dening insinyur Cisco.
Konfigurasi bench test:
- 2 x Cisco UCS Fabric Interconnect 6248UP minangka kluster manajemen lan komponen jaringan (48 bandar operasi ing Ethernet 10G / mode FC 16G).
- Papat server Cisco UCS HXAF240 M4.
Karakteristik server:
CPU
2 x Intel® Xeon® E5-2690 v4
Ram
16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/pangkat ganda/x4/1.2v
Network
UCSC-MLOM-CSC-02 (VIC 1227). 2 port Ethernet 10G
Panyimpenan HBA
Cisco 12G Modular SAS Pass liwat Controller
Disk Panyimpenan
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Pilihan konfigurasi liyaneSaliyane hardware sing dipilih, opsi ing ngisor iki saiki kasedhiya:
- HXAF240c M5.
- Siji utawa loro CPU wiwit saka Intel Silver 4110 nganti Intel Platinum I8260Y. Generasi kapindho kasedhiya.
- 24 slot memori, ngudani saka 16 GB RDIMM 2600 kanggo 128 GB LRDIMM 2933.
- Saka 6 nganti 23 disk data, siji disk caching, siji disk sistem lan siji disk boot.
Kapasitas Drives
- HX-SD960G61X-EV 960GB 2.5 Inch Enterprise Value 6G SATA SSD (1X toleransi) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2.5 inch Enterprise Value 6G SATA SSD (1X toleransi) SAS 3.8 TB.
- Caching Drives
- HX-NVMEXPB-I375 375GB 2.5 inch Intel Optane Drive, Extreme Perf & Endurance.
- HX-NVMEHW-H1600 * 1.6TB 2.5 inci Ent. Perf. NVMe SSD (3X toleransi) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 inci Ent. Perf. 12G SAS SSD (10X toleransi) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 inci Ent. Perf. 12G SAS SED SSD (10X toleransi) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 inch Enterprise kinerja 12G SAS SSD (3X toleransi).
Sistem / Log Drive
- HX-SD240GM1X-EV 240GB 2.5 inch Enterprise Value 6G SATA SSD (Mbutuhake upgrade).
Boot Drives
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Sambungake menyang jaringan liwat port Ethernet 40G, 25G utawa 10G.
FI bisa HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Tes dhewe
Kanggo nyoba subsistem disk, Aku digunakake HCIBench 2.2.1. Iki minangka sarana gratis sing ngidini sampeyan ngotomatisasi nggawe beban saka macem-macem mesin virtual. Beban dhewe digawe dening fio biasanipun.
Kluster kita kasusun saka papat simpul, faktor replikasi 3, kabeh disk yaiku Flash.
Kanggo nguji, aku nggawe papat datastore lan wolung mesin virtual. Kanggo tes nulis, dianggep yen disk caching ora kebak.
Asil tes kaya ing ngisor iki:
100% Waca 100% Random
0% Waca 100% Random
Kedalaman blok / antrian
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36ms 374348 IOPS
2.47 ms 414116 IOPS
4,86ms 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
Kandel nuduhake nilai-nilai sing sawise ora ana paningkatan produktivitas, kadhangkala uga degradasi katon. Iki amarga kasunyatan sing kita diwatesi dening kinerja jaringan / controller / disk.
- Waca urutan 4432 MB/s.
- Tulis urutan 804 MB/s.
- Yen salah siji controller gagal (gagal mesin virtual utawa inang), gulung kinerja dadi loro.
- Yen disk panyimpenan gagal, drawdown 1/3. Disk rebuild njupuk 5% saka sumber daya saben controller.
Ing blok cilik, kita diwatesi dening kinerja controller (mesin virtual), CPU dimuat ing 100%, lan nalika pamblokiran mundhak, kita diwatesi dening bandwidth port. 10 Gbps ora cukup kanggo mbukak kunci potensial sistem AllFlash. Sayange, paramèter saka stand demo sing kasedhiya ora ngidini kita nyoba operasi ing 40 Gbit / s.
Ing kesan saka tes lan nyinaoni arsitektur, amarga algoritma sing nempatake data ing antarane kabeh host, kita entuk kinerja sing bisa diukur, bisa diprediksi, nanging iki uga dadi watesan nalika maca, amarga bisa luwih akeh saka disk lokal. kene bisa nyimpen jaringan luwih produktif, Contone, FI ing 40 Gbit / s kasedhiya.
Uga, siji disk kanggo caching lan deduplikasi bisa dadi watesan; nyatane, ing testbed iki kita bisa nulis menyang papat disk SSD. Iku bakal gedhe kanggo bisa kanggo nambah jumlah drive caching lan ndeleng prabédan.
Panganggone nyata
Kanggo ngatur pusat data serep, sampeyan bisa nggunakake rong pendekatan (kita ora nganggep nggawe serep ing situs remot):
- Aktif-Pasif. Kabeh aplikasi di-host ing pusat data utama. Replikasi yaiku sinkron utawa asinkron. Yen pusat data utama gagal, kita kudu ngaktifake serep. Iki bisa ditindakake kanthi manual / skrip / aplikasi orkestrasi. Ing kene kita bakal entuk RPO sing cocog karo frekuensi replikasi, lan RTO gumantung saka reaksi lan katrampilan administrator lan kualitas pangembangan / debugging saka rencana switching.
- Aktif-Aktif. Ing kasus iki, mung ana replikasi sinkron; kasedhiyan pusat data ditemtokake dening kuorum / arbiter sing dumunung ing situs katelu. RPO = 0, lan RTO bisa tekan 0 (yen aplikasi ngidini) utawa padha karo wektu failover saka simpul ing kluster virtualisasi. Ing tingkat virtualisasi, kluster dowo (Metro) digawe sing mbutuhake panyimpenan Aktif-Aktif.
Biasane kita ndeleng manawa klien wis ngetrapake arsitektur kanthi sistem panyimpenan klasik ing pusat data utama, mula kita ngrancang siji liyane kanggo replikasi. Kaya sing dakkandhakake, Cisco HyperFlex nawakake replikasi asinkron lan nggawe kluster virtualisasi sing digawe dowo. Ing wektu sing padha, kita ora mbutuhake sistem panyimpenan khusus saka tingkat Midrange lan luwih dhuwur kanthi fungsi replikasi sing larang lan akses data Aktif-Aktif ing rong sistem panyimpenan.
Skenario 1: Kita duwe pusat data utama lan serep, platform virtualisasi ing VMware vSphere. Kabeh sistem produktif dumunung ing pusat data utama, lan replikasi mesin virtual dileksanakake ing tingkat hypervisor, iki bakal supaya VMs diuripake ing pusat data serep. Kita niru database lan aplikasi khusus nggunakake alat sing dibangun lan tetep VM diuripake. Yen pusat data utama gagal, kita miwiti sistem ing pusat data serep. Kita pitados bilih kita duwe bab 100 mesin virtual. Nalika pusat data utami operasional, pusat data siyaga bisa mbukak lingkungan tes lan sistem liyane sing bisa dipateni yen pusat data utama ngalih. Sampeyan uga bisa nggunakake replikasi rong arah. Saka sudut pandang hardware, ora ana sing bakal diganti.
Ing cilik saka arsitektur klasik, kita bakal nginstal ing saben pusat data sistem panyimpenan Sato karo akses liwat FibreChannel, tiering, deduplication lan komprèsi (nanging ora online), 8 server kanggo saben situs, 2 ngalih FibreChannel lan 10G Ethernet. Kanggo replikasi lan manajemen ngoper ing arsitektur klasik, kita bisa nggunakake alat VMware (Replikasi + SRM) utawa alat pihak katelu, sing bakal luwih murah lan kadhangkala luwih trep.
Tokoh nuduhake diagram.
Nalika nggunakake Cisco HyperFlex, arsitektur ing ngisor iki dijupuk:
Kanggo HyperFlex, aku nggunakake server kanthi sumber daya CPU / RAM gedhe, amarga ... Sawetara sumber daya bakal pindhah menyang VM pengontrol HyperFlex; ing babagan CPU lan memori, aku malah ngonfigurasi konfigurasi HyperFlex sethithik supaya ora main bareng karo Cisco lan njamin sumber daya kanggo VM sing isih ana. Nanging kita bisa nglirwakake switch FibreChannel, lan kita ora butuh port Ethernet kanggo saben server; lalu lintas lokal diuripake ing FI.
Asil konfigurasi ing ngisor iki kanggo saben pusat data:
Server
8 x 1U Server (384 GB RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (RAM 512 GB, 2 x Intel Emas 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
SHD
Sistem panyimpenan hibrida karo FC Front-End (20TB SSD, 130 TB NL-SAS)
-
LAN
2 x Ethernet ngalih 10G 12 port
-
SAN
2 x ngalih FC 32/16Gb 24 port
2 x Cisco UCS FI 6332
Lisensi
VMware Ent Plus
Replikasi lan / utawa orkestrasi VM switching
VMware Ent Plus
Aku ora nyedhiyani lisensi lunak replikasi kanggo Hyperflex, awit iki kasedhiya metu saka kothak kanggo kita.
Kanggo arsitektur klasik, aku milih vendor sing wis mantep dhewe minangka pabrikan sing berkualitas lan murah. Kanggo loro opsi, Aku Applied diskon standar kanggo solusi tartamtu, lan minangka asil aku nampa prices nyata.
Solusi Cisco HyperFlex dadi 13% luwih murah.
Skenario 2: nggawe rong pusat data aktif. Ing skenario iki, kita ngrancang kluster dowo ing VMware.
Arsitèktur klasik kasusun saka server virtualisasi, SAN (protokol FC) lan rong sistem panyimpenan sing bisa maca lan nulis kanthi volume sing ana ing antarane. Ing saben sistem panyimpenan kita sijine kapasitas migunani kanggo panyimpenan.
Ing HyperFlex, kita mung nggawe Stretch Cluster kanthi jumlah kelenjar sing padha ing situs kasebut. Ing kasus iki, faktor replikasi 2 + 2 digunakake.
Asil punika konfigurasi ing ngisor iki:
arsitektur klasik
HyperFlex
Server
Server 16 x 1U (RAM 384 GB, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)
16 x HX240C-M5L (RAM 512 GB, 2 x Intel Emas 6132, NVMe 1,6 TB, SSD 12 x 3,8 TB, VIC 1387)
SHD
2 x Sistem panyimpenan AllFlash (150 TB SSD)
-
LAN
4 x Ethernet ngalih 10G 24 port
-
SAN
4 x ngalih FC 32/16Gb 24 port
4 x Cisco UCS FI 6332
Lisensi
VMware Ent Plus
VMware Ent Plus
Ing kabeh petungan, aku ora nganggep infrastruktur jaringan, biaya pusat data, lan liya-liyane: padha karo arsitektur klasik lan solusi HyperFlex.
Ing babagan biaya, HyperFlex dadi 5% luwih larang. Iku worth kang lagi nyimak ing kene sing ing syarat-syarat CPU / sumber RAM aku skew kanggo Cisco, amarga ing konfigurasi aku kapenuhan saluran controller memori roto-roto. Biaya rada luwih dhuwur, nanging ora kanthi urutan gedhene, sing jelas nuduhake yen hyperconvergence ora kudu "dolanan kanggo wong sugih", nanging bisa saingan karo pendekatan standar kanggo mbangun pusat data. Iki bisa uga dadi kapentingan kanggo wong-wong sing wis duwe server Cisco UCS lan infrastruktur sing cocog kanggo wong-wong mau.
Antarane kaluwihan, kita entuk ora ana biaya kanggo administrasi SAN lan sistem panyimpenan, kompresi online lan deduplikasi, titik entri siji kanggo dhukungan (virtualisasi, server, uga sistem panyimpenan), ngirit ruang (nanging ora ing kabeh skenario), nyederhanakake operasi.
Kanggo dhukungan, sampeyan entuk saka siji vendor - Cisco. Miturut pengalaman karo server Cisco UCS, aku seneng; Aku ora kudu mbukak ing HyperFlex, kabeh bisa digunakake. Insinyur nanggapi kanthi cepet lan bisa ngatasi ora mung masalah khas, nanging uga kasus pinggiran sing rumit. Kadhangkala aku takon karo wong-wong mau: "Apa bisa nindakake iki, nyepetake?" utawa "Aku diatur soko kene, lan iku ora pengin bisa. Tulung!" - dheweke bakal sabar nemokake pandhuan sing dibutuhake ing kana lan nuduhake tumindak sing bener; dheweke ora bakal mangsuli: "Kita mung ngatasi masalah hardware."
referensi
- Suratku - [email dilindhungi]
Source: www.habr.com