Di IT, yang utama adalah tiga huruf
Tugas dari setiap infrastruktur TI adalah untuk menyediakan platform yang dapat diandalkan untuk proses bisnis perusahaan. Secara tradisional diyakini bahwa kualitas infrastruktur teknologi informasi dinilai berdasarkan tiga parameter utama: aksesibilitas, keamanan, keandalan. Namun, penilaian untuk triple ini sama sekali tidak terkait dengan bisnis dan pendapatan / kerugian langsung perusahaan.Tiga huruf utama mengaturnya. Jika huruf "RUB" tidak berada di puncak hirarki TI, maka Anda membangun infrastruktur IT Anda secara tidak benar. Tentu saja, sulit untuk membangun TI secara langsung, mulai hanya dari pendapatan / pengeluaran, oleh karena itu ada hierarki "tiga huruf" - dari yang paling penting hingga yang lebih pribadi. SLA, RPO, RTO, GRC - semua ini diketahui oleh para pakar industri dan telah lama digunakan dalam membangun infrastruktur. Sayangnya, tidak selalu menghubungkan indikator-indikator ini ke dalam hierarki ujung ke ujung.
Banyak perusahaan saat ini sedang membangun infrastruktur untuk masa depan menggunakan teknologi kemarin pada arsitektur kemarin. Dan pada saat yang sama, percepatan perkembangan TI menunjukkan bahwa layanan modern secara mendasar mengubah tidak hanya bisnis tetapi juga masyarakat - orang-orang di era digital terbiasa dengan kenyataan bahwa beberapa detik sudah cukup untuk mengakses informasi apa pun. TI dari teknologi yang tidak bisa dipahami telah menjadi hal biasa bagi massa, seperti burger atau kedai kopi. Ini telah menambahkan tiga huruf baru yang sangat penting ke TI. Surat-surat ini - TTM (Time to market) - waktu sebelum peluncuran layanan produktif di pasar.
Sds
Di sisi lain, kraken bangkit dari kedalaman teknologi, mengubah TI tradisional dan gaya hidup. Seiring kekuatan komputasi prosesor x86 tumbuh, sistem penyimpanan perangkat lunak menjadi tentakel pertama. Sistem penyimpanan klasik adalah potongan besi yang sangat spesifik yang diisi dengan "silikon khusus", berbagai akselerator perangkat keras berpemilik, dan perangkat lunak khusus. Dan itu dikelola oleh orang yang terlatih khusus yang praktis dipuja di perusahaan sebagai pendeta dari kultus gelap. Untuk memperluas sistem penyimpanan data yang beroperasi di perusahaan adalah keseluruhan proyek, dengan banyak perhitungan dan persetujuan - lagipula, itu mahal!Biaya tinggi dan kompleksitas mendorong penciptaan sistem penyimpanan perangkat lunak di atas perangkat keras x86 biasa dengan OS tujuan umum yang umum - Windows, Linux, FreeBSD atau Solaris. Hanya perangkat lunak yang tersisa dari perangkat keras khusus yang kompleks, yang bekerja bahkan di kernel, tetapi di tingkat pengguna. Sistem perangkat lunak pertama tentu saja cukup sederhana dan fungsionalitasnya terbatas, seringkali mereka adalah solusi khusus niche, tetapi waktu berlalu. Dan sekarang bahkan vendor sistem penyimpanan besar telah mulai meninggalkan solusi perangkat keras khusus - TTM untuk sistem seperti itu tidak dapat lagi menahan persaingan, dan biaya kesalahan menjadi sangat tinggi. Bahkan, dengan pengecualian langka, bahkan sistem penyimpanan klasik pada tahun 2020 menjadi server x86 yang paling umum, hanya dengan moncong plastik yang indah dan banyak rak disk.Tentakel kedua dari kraken yang mendekat adalah penampilan dan adopsi besar-besaran oleh pasar teknologi flash memory, yang telah menjadi pilar konkret yang mematahkan punggung gajah.Kinerja disk magnetik tidak berubah selama bertahun-tahun dan prosesor pengontrol penyimpanan sepenuhnya diatasi dengan ratusan disk. Namun sayangnya, kuantitasnya cepat atau lambat akan berubah menjadi kualitas - dan sistem penyimpanan sudah pada tingkat rata-rata, belum lagi yang pertama, ia memiliki batas atas pada jumlah flash drive yang bermakna. Dengan jumlah tertentu (secara harfiah dari sepuluh disk), kinerja sistem tidak berhenti tumbuh, tetapi juga dapat mulai menurun karena kebutuhan untuk memproses volume yang semakin besar. Bagaimanapun, kekuatan pemrosesan dan throughput dari pengendali tidak berubah dengan meningkatnya kapasitas. Solusinya, secara teori, adalah munculnya sistem scale-out yang dapat merakit banyak rak independen dengan disk dan sumber daya prosesor menjadi satu cluster yang terlihat dari luar sebagai sistem penyimpanan multi-controller tunggal. Hanya ada satu langkah lagi.Konvergensi hiper
Langkah yang paling jelas ke masa depan adalah penyatuan tempat penyimpanan dan pemrosesan data yang sebelumnya berbeda. Dengan kata lain, mengapa tidak menerapkan penyimpanan terdistribusi bukan pada server terpisah, tetapi langsung pada host virtualisasi, sehingga menolak jaringan penyimpanan khusus dan perangkat keras khusus, dan dengan demikian menggabungkan fungsi. Kraken terbangun.Tapi saya katakan, Anda tahu, karena kombinasi adalah konvergensi. Dari mana hiper awalan bodoh ini berasal?. + + . . , “ ”.
…
, , , . — SDS.
:
- — , , , /. .
- Sistem konvergen - semua dari satu sumber, satu dukungan, satu nomor mitra. Jangan bingung dengan perakitan sendiri dari satu vendor.
Dan ternyata istilah untuk arsitektur terkonvergensi kita sudah dipakai. Situasi yang sama persis dengan supervisor.
Hyperconverged System - Sistem konvergen dengan arsitektur konvergen.
Definisi diambil dari artikel " Teori Umum dan Arkeologi Virtualisasi ", yang dalam tulisannya saya mengambil bagian yang hidup.Apa yang memberikan pendekatan hyperconverged dalam aplikasi ke tiga huruf yang disebutkan?- Mulai dengan volume minimum (dan biaya minimum)
- Kapasitas penyimpanan tumbuh dengan daya komputasi
- Setiap node sistem adalah controller - dan masalah "langit-langit kaca" dihapus (disk bisa, tetapi controller tidak ada lagi)
- Manajemen penyimpanan disederhanakan secara dramatis
Untuk paragraf terakhir, sistem hyperconverged sangat tidak disukai oleh administrator penyimpanan mode lama yang digunakan untuk mengelola antrian pada port Fibre Channel. Ruang dialokasikan hanya dalam beberapa klik mouse dari konsol manajemen infrastruktur virtual.Dengan kata lain, hanya cloud yang lebih cepat dari sistem hyperconverged dalam meluncurkan suatu produk, tetapi cloud tidak cocok untuk semua orang dan / atau tidak selalu.Jika Anda seorang administrator teknologi dan membaca sampai di sini - bersukacitalah, kata-kata umum telah berakhir dan sekarang saya akan memberi tahu Anda tentang pandangan pribadi saya tentang sistem Cisco Hyperflex, yang saya dapatkan dengan cakar ulet untuk melakukan berbagai tes di atasnya.Cisco Hyperflex
Mengapa Cisco
Cisco dikenal terutama sebagai vendor dominan di pasar peralatan jaringan, tetapi pada saat yang sama ia cukup banyak hadir di segmen lain dari pasar pusat data, menawarkan solusi server dan hyperconverged, serta sistem otomatisasi dan kontrol.Anehnya, pada tahun 2020, masih ada orang: “Server Cisco? Dan dari siapa dia mengambilnya? ”Cisco mulai menangani server pada tahun 2009, memilih jalur solusi blade yang aktif tumbuh pada saat itu. Gagasan Cisco adalah menerapkan pendekatan kalkulator anonim. Hasilnya adalah sistem UCS (Unified Computing System) yang terdiri dari dua sakelar khusus (mereka disebut Fabric Interconnect), dan dari 1 hingga 20 sasis (8 bilah berukuran setengah) atau hingga 160 server. Pada saat yang sama, sasis umumnya menjadi bodoh dengan sepotong besi dengan kekuatan, semua logika dan switching dibuat dalam Fabric Interconnect; sasis hanyalah cara untuk meng-host server dan menghubungkannya ke sistem. Fabric Interconnect bertanggung jawab penuh atas semua interaksi server dengan dunia luar - Ethernet, FC, dan manajemen. Tampaknya bilah dan bilah, apa yang ada di sana, kecuali untuk switching eksternal, dan tidak seperti orang lain di sasis.Momen kunci dalam implementasi “kalkulator anonim” yang sama. Sebagai bagian dari konsep Cisco UCS, server tidak memiliki kepribadian selain nomor seri. Baik MAC, WWN, atau yang lainnya. Sistem manajemen UCS yang diberdayakan oleh Fabric Interconnect didasarkan pada profil dan templat server. Setelah menghubungkan satu bundel server dalam sasis, mereka harus diberi profil yang sesuai, di mana semua alamat dan pengidentifikasi ditetapkan. Tentu saja, jika Anda hanya memiliki selusin server, maka permainan tidak akan sia-sia. Tetapi ketika setidaknya ada dua, atau bahkan tiga lusin dari mereka, ini adalah keuntungan yang serius. Menjadi mudah dan cepat untuk melakukan migrasi konfigurasi, atau, yang lebih penting, untuk mereplikasi konfigurasi server dalam jumlah yang tepat, segera menerapkan perubahan ke sejumlah besar server,pada dasarnya mengelola satu set server (misalnya, sebuah ladang virtualisasi) sebagai satu kesatuan. Pendekatan yang diusulkan dalam sistem UCS memungkinkan, dengan pendekatan yang tepat, untuk secara serius menyederhanakan kehidupan administrator, meningkatkan fleksibilitas dan secara signifikan mengurangi risiko, sehingga bilah UCS secara harfiah dalam 2-3 tahun telah menjadi platform blade terlaris di Belahan Barat, dan saat ini mereka secara global salah satu dari dua platform dominan, bersama dengan HPE.Dengan cepat menjadi jelas bahwa pendekatan yang sama berdasarkan pada pabrik universal dengan manajemen terintegrasi berdasarkan kebijakan dan templat sangat diminati dan tidak hanya berlaku untuk blade, tetapi juga untuk rak server. Dan dalam hal ini, server rack-mount Cisco yang terhubung ke Fabric Interconnect mendapatkan semua manfaat yang sama yang menjadikan blade begitu populer.Hari ini saya akan berbicara tentang HyperFlex, solusi Cisco hyperconverged yang dibangun di server rack-mount yang terhubung ke Fabric Interconnect. Apa yang membuat HyperFlex menarik dan layak dipertimbangkan dalam ulasan:- Cisco , , «» – , HyperFlex; , , , HyperFlex ;
- – ; HyperFlex , , ; , .
- « » — « », , ;
- Fabric Interconnect Cisco -, SAN , native FC;
- “” – , , ;
- Cisco , , , ;
- , , Cisco HCI, , HyperFlex , , .
HyperFlex adalah sistem hyperconverged sejati dengan VM pengontrol khusus. Biarkan saya mengingatkan Anda bahwa keuntungan utama dari arsitektur seperti itu adalah portabilitas potensial untuk hypervisor yang berbeda. Hari ini, Cisco telah mengimplementasikan dukungan untuk VMware ESXi dan Microsoft Hyper-V, tetapi ada kemungkinan bahwa salah satu opsi KVM akan muncul ketika popularitasnya tumbuh di segmen korporat.Pertimbangkan mekanisme kerja pada contoh ESXi.Perangkat yang menggunakan teknologi VM_DIRECT_PATH - disk cache dan disk level penyimpanan - langsung dilemparkan ke VM pengontrol (selanjutnya disebut CVM). Oleh karena itu, kami mengecualikan efek tumpukan disk hypervisor pada kinerja. Paket VIB tambahan dipasang di hypervisor itu sendiri:- IO Visor: menyediakan titik pemasangan untuk NFS datastore untuk hypervisor
- VAAI: VMware API « »
Blok disk virtual didistribusikan secara merata di semua host dalam satu cluster dengan granularity yang relatif kecil. Ketika VM di host melakukan beberapa operasi disk, melalui tumpukan disk hypervisor operasi pergi ke datastore, lalu ke IO Visor, dan kemudian beralih ke CVM yang bertanggung jawab untuk blok ini. Dalam hal ini, CVM dapat ditemukan di semua host di cluster. Mengingat sumber daya IO Visor yang sangat terbatas, tentu saja tidak ada tabel metadata dan pilihannya ditentukan secara matematis. Selanjutnya, CVM yang diminta datang untuk memprosesnya. Dalam hal membaca, ia mengirim data baik dari salah satu level cache (RAM, tulis cache, baca cache) atau dari disk hostnya. Dalam hal rekaman, ia menulis ke jurnal lokal, dan menduplikasi operasi untuk satu (RF2) atau dua (RF3) CVM.
Mungkin ini cukup untuk memahami prinsip kerja dalam kerangka publikasi ini, jika tidak saya akan mengambil roti dari pelatih Cisco, dan saya akan malu. Tidak juga, tapi masih cukup.Pertanyaan tentang tes sintetik
- Navigator, peralatan!- 36!- Apa itu 36?- Bagaimana dengan peralatan?Sesuatu seperti ini hari ini terlihat seperti kebanyakan pengujian sistem penyimpanan sintetis. Mengapa demikian?Sampai relatif baru-baru ini, sebagian besar sistem penyimpanan datar dengan akses seragam. Apa artinya ini?Total ruang disk yang tersedia dikumpulkan dari disk dengan karakteristik yang sama. Misalnya, 300 15k drive. Dan kinerjanya sama di seluruh ruang. Dengan munculnya teknologi penyimpanan berjenjang, sistem penyimpanan menjadi tidak rata - kinerja bervariasi dalam satu ruang disk tunggal. Dan itu tidak hanya berbeda, tetapi juga tidak dapat diprediksi, tergantung pada algoritma dan kemampuan model penyimpanan tertentu.Dan semuanya tidak akan begitu menarik jika sistem hyperconverged dengan lokalisasi data tidak muncul. Selain ketidakrataan ruang disk itu sendiri (menguras, flash cache), ada juga akses yang tidak rata - tergantung pada apakah salah satu salinan data terletak pada disk lokal dari node atau harus diakses melalui jaringan. Semua ini mengarah pada fakta bahwa jumlah tes sintetik dapat benar-benar ada, dan tidak berbicara tentang apa pun yang praktis bermakna. Misalnya, konsumsi bahan bakar mobil sesuai dengan brosur iklan yang tidak pernah bisa Anda capai di kehidupan nyata.Pertanyaan tentang ukuran
Sisi lain dari angka uji sintetik adalah angka ukuran dan spesifikasi dari bawah keyboard presale. Presales dalam hal ini dibagi menjadi dua kategori - beberapa hanya dengan bodohnya memalu TK Anda ke dalam konfigurator vendor, dan yang kedua akan mengambilnya sendiri, karena mereka mengerti cara kerjanya. Tetapi dengan yang kedua Anda harus mempertimbangkan secara rinci apa yang Anda tulis di TK Anda.Seperti yang Anda tahu, tanpa TK yang jelas - hasil HZ.
Dari pengalaman praktis - ketika mengukur sistem hyperconverged yang agak berat dalam persaingan dengan salah satu pelanggan, saya pribadi, setelah pilot, mengambil indikator beban dari sistem dan membandingkannya dengan apa yang ditulis dalam TOR. Ternyata seperti lelucon:- Rabinovich, apakah benar Anda menang satu juta dalam lotre?
- Oh, siapa yang memberitahumu itu? Tidak satu juta, tapi sepuluh rubel, bukan dalam lotre, tetapi dalam preferensi, dan tidak menang, tetapi kalah.
Dengan kata lain, situasi GIGO klasik - Sampah Masuk Sampah - Sampah Masuk = Sampah di keluaran.Ukuran praktis yang berlaku untuk hyperconvergence hampir dijamin dari dua jenis: bawa kami dengan margin, atau untuk waktu yang lama kami akan mengemudikan pilot dan mengambil indikator.Ada satu hal lagi dengan ukuran dan evaluasi spesifikasi. Sistem yang berbeda dibangun secara berbeda dan bekerja secara berbeda dengan disk, pengontrolnya berinteraksi secara berbeda. Oleh karena itu, praktis tidak ada gunanya membandingkan "head-to-head" sesuai dengan spesifikasi jumlah dan volume disk. Anda memiliki beberapa jenis TK, di mana Anda memahami tingkat beban. Dan kemudian ada sejumlah gearbox tertentu, di mana Anda ditawarkan berbagai sistem yang memenuhi persyaratan untuk kinerja dan keandalan. Apa perbedaan mendasar, berapa biaya disk dan jenis apa dalam sistem 1, dan bahwa dalam sistem 2 ada lebih / kurang dari keduanya jika keduanya berhasil mengatasi tugas.Karena kinerja sering ditentukan oleh pengendali yang hidup di host yang sama dengan mesin virtual, untuk beberapa jenis beban, ia dapat melayang secara signifikan hanya karena prosesor dengan frekuensi berbeda berdiri di kelompok yang berbeda, semua hal lain dianggap sama.Dengan kata lain, bahkan arsitek-archmage presale paling berpengalaman tidak akan memberi tahu Anda spesifikasi lebih tepatnya daripada Anda merumuskan persyaratan, dan lebih tepatnya, daripada "well, somewhere SAM-VOSEM" tanpa proyek percontohan.
Tentang snapshot
HyperFlex dapat melakukan snapshot asli dari mesin virtual menggunakan teknologi Redirect-on-Write. Dan di sini perlu untuk berhenti secara terpisah untuk mempertimbangkan berbagai teknologi snapshot.Awalnya, ada snapshot dari tipe Copy-on-Write (CoW), dan snapshot asli VMware vSphere dapat diambil sebagai contoh klasik. Prinsip operasi adalah sama dengan vmdk di atas VMFS atau NFS, yang dengan sistem file asli seperti VSAN. Setelah membuat snapshot CoW, data asli (blok atau file vmdk) dibekukan, dan ketika Anda mencoba menulis ke blok beku, salinan dibuat dan data ditulis ke blok / file baru (file delta untuk vmdk). Akibatnya, ketika pohon snapshot tumbuh, jumlah disk "palsu" yang tidak membawa makna produktif meningkat, danpenurunan / penundaan kinerja meningkat .Kemudian snapshot Redirect-on-Write (RoW) ditemukan, di mana alih-alih membuat salinan blok dengan data, salinan metadata dibuat, dan catatan hanya berjalan tanpa penundaan dan pembacaan serta pemeriksaan tambahan. Dengan penerapan snapshot RoW yang benar, efeknya hampir nol pada kinerja sistem disk. Efek kedua bekerja dengan metadata bukan data langsung itu sendiri tidak hanya pembuatan snapshot instan, tetapi juga klon VM, yang segera setelah pembuatan tidak memakan tempat sama sekali (kami tidak mempertimbangkan overhead sistem untuk file layanan VM).Dan yang ketiga, titik kunci yang secara radikal membedakan foto RoW dari foto CoW untuk sistem produktif adalah penghapusan foto secara instan. Tampaknya ini benar? Namun, Anda perlu mengingat cara kerja snapshot CoW dan bahwa menghapus snapshot bukan benar-benar penghapusan delta, melainkan komit. Dan di sini waktu komitnya sangat tergantung pada ukuran akumulasi delta dan kinerja sistem disk. Snapshots RoW dilakukan secara instan hanya karena tidak peduli berapa banyak terabyte perbedaan menumpuk, menghapus (melakukan) snapshot RoW adalah pembaruan dari tabel metadata.Dan di sini aplikasi snapshot RoW yang menarik muncul - jatuhkan RPO ke nilai puluhan menit. Membuat cadangan setiap 30 menit hampir tidak mungkin dalam kasus umum, dan dalam kebanyakan kasus mereka dilakukan sekali sehari, yang memberikan RPO 24 jam. Tetapi pada saat yang sama, kita bisa melakukan snapshot RoW sesuai jadwal, membuat RPO menjadi 15-30 menit, dan menyimpannya selama satu atau dua hari. Tidak ada penalti untuk kinerja, hanya menghabiskan kapasitas.Namun ada beberapa nuansa.Untuk pengoperasian yang tepat dari snapshot asli dan integrasi dengan VMware, HyperFlex memerlukan snapshot resmi yang disebut Sentinel. Snapshot sentinel dibuat secara otomatis ketika Anda pertama kali membuat snapshot untuk VM yang diberikan melalui HXConnect, dan Anda tidak boleh menghapusnya, Anda tidak boleh "kembali" ke sana, Anda hanya perlu memasang fakta bahwa di antarmuka dalam daftar snapshot ini adalah snapshot layanan pertama dari Sentinel.
Snapshots HyperFlex dapat berjalan dalam mode konsisten-kecelakaan atau dalam mode konsisten-aplikasi. Tipe kedua melibatkan "flushing buffer" di dalam VM, itu membutuhkan VMTools, dan itu dimulai jika kotak centang "Quiesce" dicentang di menu snapshot HXConnect.Selain snapshot HyperFlex, tidak ada yang melarang penggunaan snapshot VMware "asli". Penting untuk mesin virtual tertentu untuk menentukan foto mana yang akan Anda gunakan, dan di masa depan untuk fokus pada teknologi ini, "tidak mengganggu" foto yang berbeda untuk satu VM.Sebagai bagian dari pengujian, saya mencoba membuat snapshot dan memeriksa FIO mereka. Namun, ya, saya dapat mengonfirmasi bahwa snapshot benar-benar RoW, mereka tidak memengaruhi kinerja. Snapshots benar-benar dibuat dengan cepat (beberapa detik tergantung pada profil beban dan ukuran dataset), menurut hasil yang saya dapat memberikan rekomendasi berikut: jika beban Anda memiliki banyak operasi penulisan acak, Anda harus mulai membuat snapshot dari antarmuka HXConnect, dengan tanda centang "Quiesce" dan dengan pendahuluan keberadaan foto Sentinel.Tes
Platform uji
Platform berikut jatuh ke kaki yang ulet:- 4 x C220 M4 (2630v4 10c x 2.20 GHz, 256, 800 + 6 * 960)
- vSphere 6.7
- Platform Data HX 4.0.2
Bersihkan uji tempel
Apa jenis pengujian tanpa CrystalDisk? Itu benar, ini tidak mungkin, orang normal selalu memulai disk yang dikristalisasi! Nah, jika itu perlu, maka itu perlu.
Untuk disk kristal, VM yang dibuat khusus dengan 2 vCPU 4GB dan Windows 7 on board telah dibuat. Oh, dan aku muak meletakkan tambalan di atasnya, aku akan memberitahumu! Tes dilakukan dalam tradisi terbaik rumah-rumah terbaik di London dan Paris - yaitu, hanya satu disk virtual berikutnya-berikutnya-selesai ditambahkan tanpa pemikiran dan tes diluncurkan. Ya, dan omong-omong, tentu saja CrystalDiskMark sendiri tidak terlibat dalam pengujian, itu hanya sebuah antarmuka, tetapi secara langsung memuat sistem disk dengan paket DiskSpd terkenal yang termasuk dalam kit.
Apa yang menurut saya benar-benar - untuk beberapa alasan, semua melewatkan pilihan unit di sudut kanan atas. Dan anggaplah op!
Dengar, jujur, saya tidak berharap 75 ribu IOPS dan lebih dari 1 gigabyte per detik dari mikromachine dalam mode next-next-finish!Singkatnya, tidak setiap perusahaan di Rusia memiliki muatan yang melebihi indikator ini secara total.Tes lebih lanjut dilakukan dengan menggunakan VMware HCI Bench dan Nutanix XRay, sebagai "bermusuhan secara ideologis" dengan HyperFlex, dan oleh karena itu, diharapkan bahwa kami tidak akan mengambil tahanan. Jumlahnya ternyata sangat dekat, sehingga hasil dari paket XRay diambil sebagai dasar hanya karena memiliki sistem pelaporan yang lebih nyaman dan template pemuatan yang siap pakai.Bagi mereka yang tidak mempercayai siapa pun dan ingin kontrol penuh atas proses, saya mengingatkan Anda tentang artikel saya tentang membangun sistem Anda sendiri untuk menghasilkan beban pada platform hyperconverged - "Pengujian Kinerja sistem giperkonvergentnyh dan SDS dengan tangan mereka sendiri "Achtung! Uwaga! Pozor!
Semua hasil lebih lanjut dan interpretasinya adalah pendapat penulis artikel, dan diberikan sendiri dalam kerangka studi sistem. Sebagian besar tes adalah sintetis telanjang dan hanya berlaku untuk memahami indikator batas dalam kasus-kasus ekstrim dan merosot, yang tidak akan pernah Anda capai dalam kehidupan nyata.FourCorners Microbenchmark
Microtest 4-sisi dirancang untuk mengevaluasi sistem "cepat" untuk kinerja teoritis tertinggi dan kinerja puncak pengendali. Aplikasi praktis untuk pengujian ini adalah untuk memeriksa sistem segera setelah peluncuran untuk setiap kesalahan konfigurasi dan lingkungan, terutama kesalahan jaringan. Itu jika Anda secara teratur menjalankan sistem seperti itu, maka Anda hanya tahu angka apa yang Anda harapkan "jika semuanya baik-baik saja".
Angka akhir: 280k / 174k IOPS, 3,77 / 1,72 GBps (baca / tulis)Bagaimana perilaku pengontrol kami?
Dari yang dapat dicatat bahwa total konsumsi sumber daya untuk 4 pengontrol dan 4 beban VM adalah 49 core 2.2. Menurut statistik VMware, pemanfaatan CPU dari pengontrol mencapai 80%, mis. pada kenyataannya, kinerja dibatasi oleh kinerja pengontrol, dan khususnya prosesor. Kecepatan operasi sekuensial secara khusus bersandar pada kecepatan jaringan 10G.Mari coba lagi. Kinerja puncak pada kluster 4-simpul kecil dengan bukan prosesor 2.2GHz tercepat hampir 300 ribu IOPS pada ketinggian 4U.Percakapan "di sini kita memiliki 10, 20 atau bahkan 40% lebih / kurang" praktis tidak ada artinya karena urutan angka. Sama seperti mulai mengukur "dan saya dapat memiliki mobil 240, saya memiliki 280" meskipun faktanya adalah 80.280k / 4 node memberikan kinerja puncak 70k / node, yang misalnya melebihi angka dari kalkulator VMware VSAN, yang mengasumsikan bahwa simpul AF mengeluarkan tidak lebih dari 46k per grup disk. Dalam kasus kami, di sini dalam terminologi VMware hanya ada satu grup disk, yang sebenarnya berjalan pada x1.8.Pengaruh Ukuran Blok Datastore
Saat membuat datastore HyperFlex, Anda dapat memilih ukuran blok data - 4k atau 8k.Apa pengaruhnya? Jalankan tes segi empat yang sama.
Jika gambarnya hampir identik dengan membaca, maka catatan tentang hal-hal sebaliknya. Tes segi empat menggunakan beban 8k.Jumlah total: 280k / 280k, 172-158k / 200-180k (4k 8k). Ketika ukuran blok cocok, + 15% dari kinerja penulisan diperoleh. Jika Anda mengharapkan sejumlah besar rekaman dengan blok kecil (4k) di dalam beban - buat datastore untuk beban khusus ini dengan blok 4k, jika tidak gunakan 8k.Simulator OLTP
Gambaran yang lebih dekat dengan kenyataan diberikan oleh tes lain. Sebagai bagian dari itu, dua generator diluncurkan dengan profil dekat dengan DBMS transaksional dan level beban 6000 + 400 IOPS. Di sini, penundaan diukur, yang harus tetap pada level rendah yang stabil.
Penundaan untuk beban VM adalah 1,07 / 1,08 ms. Semua dalam semua hasil yang bagus, tapi mari kita tambahkan panas!Colokasi Basis Data: Intensitas Tinggi
Bagaimana basis transaksi akan berperilaku, tergantung pada penundaan, jika tiba-tiba tetangga yang berisik terbentuk. Yah, sangat berisik.
Jadi, basis OLTP pada simpul 1 menghasilkan 4200 IOPS pada keterlambatan 0,85 ms. Apa yang terjadi setelah sistem DSS tiba-tiba mulai menggunakan sumber daya dalam operasi berurutan?Dua generator pada node 2 dan 3 memuat platform pada 1,18 / 1,08 GBps, masing-masing, total 2,26 GBps. Penundaan pada OLTP tentu saja tumbuh dan menjadi kurang datar, tetapi nilai rata-rata tetap 1,85 ms, dan pangkalan menerima 4200 IOPS tanpa masalah.Dampak snapshot
Sistem secara berurutan mengambil beberapa foto sekali dalam satu jam pada basis OLTP. Tidak ada yang mengejutkan dalam jadwal, dan terlebih lagi, ini umumnya merupakan indikator bagaimana snapshot klasik VMware bekerja, karena Nutanix XRay tidak tahu bagaimana bekerja dengan snapshot asli kecuali untuk snapshot asli. Anda tidak perlu menggunakan snapshot vSphere secara teratur, karena tidak semua yogurt sama bermanfaatnya.Snapshots asli HyperFlex berfungsi lebih baik, gunakan dan rambut Anda akan menjadi lembut dan halus!Konsumsi data besar
Bagaimana HyperFlex akan mencerna sejumlah besar data yang diunggah secara berurutan? Katakanlah 1TB.
Tes ini memakan waktu 27 menit, termasuk mengkloning, menyetel, dan memulai generator.Skalabilitas throughput
Sekarang, secara bertahap memuat seluruh cluster dan melihat angka yang stabil. Untuk mulai dengan membaca acak, lalu menulis.
Kami melihat gambar yang stabil dengan penurunan bertahap dalam kinerja beban alat berat dari 78k menjadi 55-57k IOPS, dengan rak yang halus. Pada saat yang sama, ada peningkatan yang stabil dalam kinerja keseluruhan dari 78 menjadi 220k IOPS.
Perekaman sedikit kurang mulus, tetapi rak-rak yang stabil dari 64k ke 19-21k per mobil. Pada saat yang sama, beban pada pengontrol jauh lebih rendah. Jika saat membaca total level beban prosesor meningkat dari 44 menjadi 109, maka saat merekam dari 57 menjadi 73 GHz.Di sini Anda dapat mengamati contoh paling sederhana dan paling jelas dari fitur sistem hyperconverged - satu-satunya konsumen tidak dapat sepenuhnya memanfaatkan semua sumber daya sistem, dan ketika beban ditambahkan, tidak ada penurunan kinerja yang signifikan. Penurunan yang kita saksikan sudah merupakan hasil dari beban sintetik ekstrem yang dirancang untuk memeras segala sesuatu hingga tetes terakhir, yang hampir tidak pernah terjadi pada produk normal.Melanggar OLTP
Pada saat ini, bahkan menjadi membosankan bagaimana HyperFlex dapat diprediksi. Kebutuhan mendesak untuk memecahkan sesuatu!
Titik merah menandai saat VM controller dimatikan pada salah satu host dengan beban.Karena secara default membangun kembali di HyperFlex dimulai segera hanya ketika disk hilang, dan ketika simpul hilang, batas waktu adalah 2 jam, saat pembangunan kembali paksa ditandai dengan titik hijau.login as: admin
HyperFlex StorageController 4.0(2a)
admin@192.168.***.***'s password:
<b>admin@SpringpathController0VY9B6ERXT:~$</b> stcli rebalance status
rebalanceStatus:
percentComplete: 0
rebalanceState: cluster_rebalance_not_running
rebalanceEnabled: True
<b>admin@SpringpathController0VY9B6ERXT:~$</b> stcli rebalance start -f
msgstr: Successfully started rebalance
params:
msgid: Successfully started rebalance
<b>admin@SpringpathController0VY9B6ERXT:~$</b> stcli rebalance status
rebalanceStatus:
percentComplete: 16
rebalanceState: cluster_rebalance_ongoing
rebalanceEnabled: True
<b>admin@SpringpathController0VY9B6ERXT:~$</b>
Operasi membeku selama beberapa detik dan melanjutkan lagi, hampir memperhatikan pembangunan kembali. Itu dalam keadaan stabil ketika jauh dari cluster yang berlebihan.Mengapa 2 jam Cisco bukan masalah, meskipun kompetitor memiliki jumlah yang lebih sedikit? Cisco sangat merekomendasikan penggunaan RF3 sebagai tingkat dasar perlindungan data untuk semua hal kecuali mesin yang tidak disayangkan. Anda memutuskan untuk menginstal tambalan atau melakukan sesuatu dengan tuan rumah, matikan. Dan ada kemungkinan bahwa pada saat itu host lain akan gagal - dan kemudian dalam kasus RF2 semuanya akan menjadi taruhan, dan dengan RF3 akan ada satu salinan data yang aktif. Dan ya, memang, sangat mungkin untuk bertahan 2 jam dalam kecelakaan di RF2 sampai pemulihan ke RF3 dimulai.Hancurkan aku sepenuhnya!
Breaking - jadi break. Penuh. Dalam hal ini, saya membuat tes dengan profil yang kurang lebih menyerupai beban nyata (70% baca, 20% acak, 8k, 6d 128q).
Tebak di mana CVM dimatikan, dan di mana pembangunan kembali dimulai?
Dalam situasi dengan pembangunan kembali, HyperFlex berkinerja cukup baik, tanpa menyebabkan penurunan kinerja yang dahsyat atau peningkatan banyak penundaan, bahkan di bawah beban di bawah tomat yang sangat. Satu-satunya hal yang saya benar-benar suka adalah Cisco sayang, membuat batas waktu semua sama kurang dari 2 jam secara default.temuan
Sebagai penutup, saya ingat tujuan pengujian: untuk menyelidiki sistem Cisco HyperFlex hari ini, tanpa melihat sejarah, untuk menyelidiki kinerjanya menggunakan sintetis dan menarik kesimpulan tentang penerapannya pada produk nyata.Kesimpulan 1 , tentang kinerja. Performanya sangat bagus, dan Anda tidak akan memberikan komentar lain di sini. Karena saya memiliki sistem generasi sebelumnya dalam pengujian, saya dapat mengatakan dengan tepat satu hal - pada HyperFlex All Flash Anda akan menjalankan kapasitas, ke prosesor, ke dalam memori, tetapi tidak ke dalam disk. Kecuali mungkin 1% dari aplikasi super-dimuat, tetapi Anda perlu melakukan percakapan dengan mereka secara pribadi. Jepretan RoW Asli bekerja.Kesimpulan 2, dengan ketersediaan. Sistem setelah mendeteksi kegagalan cukup baik (tanpa penurunan kinerja kadang-kadang) memenuhi pemulihan jumlah salinan data. Ada sedikit keluhan dalam batas waktu default 2 jam sebelum memulai pemulihan (jika host hilang), tetapi mengingat RF3 yang sangat direkomendasikan, ini lebih menarik. Pemulihan setelah kegagalan disk dimulai segera.Kesimpulan 3, dalam harga dan perbandingan dengan pesaing. Harga sistem dapat bervariasi berkali-kali tergantung pada konfigurasi untuk proyek tertentu. Bagian besar dari biaya proyek akan menjadi sistem berlisensi dan perangkat lunak aplikasi, yang akan bekerja di atas platform infrastruktur. Oleh karena itu, satu-satunya cara untuk membandingkan dengan pesaing adalah membandingkan penawaran komersial spesifik yang memenuhi persyaratan teknis, khusus untuk perusahaan Anda untuk proyek tertentu.Kesimpulan akhir : sistem bekerja, cukup matang untuk digunakan dalam produk untuk April 2020, jika rekomendasi vendor dibaca dan diterapkan, daripada merokok.