Ini adalah mitos yang cukup umum terjadi di bidang hardware server. Dalam praktiknya, solusi hiperkonvergensi (ketika semuanya menjadi satu) diperlukan untuk banyak hal. Secara historis, arsitektur pertama dikembangkan oleh Amazon dan Google untuk layanan mereka. Kemudian idenya adalah membuat sebuah peternakan komputasi dari node yang identik, yang masing-masing memiliki disknya sendiri. Semua ini disatukan oleh beberapa perangkat lunak pembentuk sistem (hypervisor) dan dibagi menjadi mesin virtual. Tujuan utamanya adalah upaya minimal untuk melayani satu node dan minimal masalah penskalaan: cukup beli seribu atau dua server yang sama dan sambungkan di dekatnya. Dalam praktiknya, ini adalah kasus yang terisolasi, dan lebih sering kita berbicara tentang jumlah node yang lebih sedikit dan arsitektur yang sedikit berbeda.
Namun kelebihannya tetap sama – kemudahan penskalaan dan pengelolaan yang luar biasa. Kelemahannya adalah tugas yang berbeda menghabiskan sumber daya secara berbeda, dan di beberapa tempat akan terdapat banyak disk lokal, di tempat lain akan ada sedikit RAM, dan seterusnya, untuk jenis tugas yang berbeda, pemanfaatan sumber daya akan berkurang.
Ternyata Anda membayar 10–15% lebih banyak untuk kemudahan penyiapan. Hal inilah yang memicu mitos pada judul tersebut. Kami menghabiskan waktu lama mencari di mana teknologi akan diterapkan secara optimal, dan kami menemukannya. Faktanya adalah Cisco tidak memiliki sistem penyimpanan sendiri, namun mereka menginginkan pasar server yang lengkap. Dan mereka membuat Cisco Hyperflex - solusi dengan penyimpanan lokal pada node.
Dan ini tiba-tiba menjadi solusi yang sangat baik untuk cadangan pusat data (Disaster Recovery). Saya akan memberi tahu Anda alasan dan caranya sekarang. Dan saya akan menunjukkan tes clusternya.
Dimana diperlukan
Hiperkonvergensi adalah:
- Mentransfer disk ke node komputasi.
- Integrasi penuh subsistem penyimpanan dengan subsistem virtualisasi.
- Transfer/integrasi dengan subsistem jaringan.
Kombinasi ini memungkinkan Anda mengimplementasikan banyak fitur sistem penyimpanan pada tingkat virtualisasi dan semuanya dari satu jendela kontrol.
Di perusahaan kami, proyek untuk merancang pusat data redundan sangat diminati, dan solusi hiperkonvergensi sering kali dipilih karena banyaknya opsi replikasi (hingga metrokluster) yang siap pakai.
Dalam kasus pusat data cadangan, kita biasanya berbicara tentang fasilitas jarak jauh di lokasi di sisi lain kota atau di kota lain. Ini memungkinkan Anda memulihkan sistem penting jika terjadi kegagalan sebagian atau seluruhnya pada pusat data utama. Data penjualan terus-menerus direplikasi di sana, dan replikasi ini dapat terjadi pada tingkat aplikasi atau pada tingkat perangkat blok (penyimpanan).
Oleh karena itu, sekarang saya akan berbicara tentang desain dan pengujian sistem, dan kemudian tentang beberapa skenario aplikasi kehidupan nyata dengan penghematan data.
Uji
Mesin virtual kami terdiri dari empat server, yang masing-masing memiliki 10 drive SSD berukuran 960 GB. Ada disk khusus untuk menyimpan cache operasi penulisan dan menyimpan mesin virtual layanan. Solusinya sendiri adalah versi keempat. Yang pertama sejujurnya kasar (dilihat dari ulasannya), yang kedua lembab, yang ketiga sudah cukup stabil, dan yang ini bisa disebut rilis setelah pengujian beta untuk masyarakat umum berakhir. Selama pengujian saya tidak melihat adanya masalah, semuanya bekerja seperti jam.
Perubahan di v4Banyak bug telah diperbaiki.
Awalnya, platform ini hanya dapat bekerja dengan hypervisor VMware ESXi dan mendukung sejumlah kecil node. Selain itu, proses penerapan tidak selalu berakhir dengan sukses, beberapa langkah harus dimulai ulang, ada masalah saat memperbarui dari versi yang lebih lama, data di GUI tidak selalu ditampilkan dengan benar (walaupun saya masih kurang puas dengan tampilan grafik kinerja ), terkadang muncul masalah pada antarmuka dengan virtualisasi.
Sekarang semua masalah masa kanak-kanak telah diperbaiki, HyperFlex dapat menangani ESXi dan Hyper-V, ditambah lagi dimungkinkan untuk:
- Membuat cluster yang membentang.
- Membuat cluster untuk kantor tanpa menggunakan Fabric Interconnect, dari dua hingga empat node (kami hanya membeli server).
- Kemampuan untuk bekerja dengan sistem penyimpanan eksternal.
- Dukungan untuk container dan Kubernetes.
- Penciptaan zona ketersediaan.
- Integrasi dengan VMware SRM jika fungsionalitas bawaannya tidak memuaskan.
Arsitekturnya tidak jauh berbeda dengan solusi pesaing utamanya, mereka tidak menciptakan sepeda. Semuanya berjalan pada platform virtualisasi VMware atau Hyper-V. Perangkat keras di-host di server Cisco UCS berpemilik. Ada yang membenci platform karena kompleksitas relatif dari pengaturan awal, banyak tombol, sistem templat dan dependensi yang tidak sepele, tetapi ada juga yang telah mempelajari Zen, terinspirasi oleh ide tersebut dan tidak lagi menginginkannya. untuk bekerja dengan server lain.
Kami akan mempertimbangkan solusi untuk VMware, karena solusi tersebut awalnya dibuat untuknya dan memiliki lebih banyak fungsi; Hyper-V ditambahkan untuk mengimbangi pesaing dan memenuhi ekspektasi pasar.
Ada sekelompok server yang penuh dengan disk. Ada disk untuk penyimpanan data (SSD atau HDD - sesuai selera dan kebutuhan), ada satu disk SSD untuk caching. Saat menulis data ke penyimpanan data, data disimpan pada lapisan caching (disk SSD khusus dan RAM dari layanan VM). Secara paralel, satu blok data dikirim ke node di cluster (jumlah node bergantung pada faktor replikasi cluster). Setelah konfirmasi dari semua node tentang keberhasilan perekaman, konfirmasi rekaman dikirim ke hypervisor dan kemudian ke VM. Data yang direkam dihapus duplikatnya, dikompresi dan ditulis ke disk penyimpanan di latar belakang. Pada saat yang sama, blok besar selalu ditulis ke disk penyimpanan dan secara berurutan, yang mengurangi beban pada disk penyimpanan.
Deduplikasi dan kompresi selalu diaktifkan dan tidak dapat dinonaktifkan. Data dibaca langsung dari disk penyimpanan atau dari cache RAM. Jika konfigurasi hibrid digunakan, pembacaan juga disimpan dalam cache di SSD.
Data tidak terikat dengan lokasi mesin virtual saat ini dan didistribusikan secara merata antar node. Pendekatan ini memungkinkan Anda memuat semua disk dan antarmuka jaringan secara merata. Ada kelemahan yang jelas: kami tidak dapat mengurangi latensi baca sebanyak mungkin, karena tidak ada jaminan ketersediaan data secara lokal. Namun saya yakin ini hanyalah pengorbanan kecil dibandingkan manfaat yang diterima. Selain itu, penundaan jaringan telah mencapai nilai sedemikian rupa sehingga praktis tidak mempengaruhi hasil keseluruhan.
Pengontrol VM Cisco HyperFlex Data Platform layanan khusus, yang dibuat pada setiap node penyimpanan, bertanggung jawab atas seluruh logika operasi subsistem disk. Dalam konfigurasi VM layanan kami, delapan vCPU dan 72 GB RAM dialokasikan, jumlah yang tidak sedikit. Izinkan saya mengingatkan Anda bahwa host itu sendiri memiliki 28 inti fisik dan RAM 512 GB.
VM layanan memiliki akses ke disk fisik secara langsung dengan meneruskan pengontrol SAS ke VM. Komunikasi dengan hypervisor terjadi melalui modul khusus IOVisor, yang mencegat operasi I/O, dan menggunakan agen yang memungkinkan Anda mengirim perintah ke API hypervisor. Agen bertanggung jawab untuk bekerja dengan snapshot dan klon HyperFlex.
Sumber daya disk dipasang di hypervisor sebagai NFS atau SMB yang dibagikan (tergantung pada jenis hypervisor, tebak di mana tempatnya). Dan di baliknya, ini adalah sistem file terdistribusi yang memungkinkan Anda menambahkan fitur sistem penyimpanan lengkap dewasa: alokasi volume tipis, kompresi dan deduplikasi, snapshot menggunakan teknologi Redirect-on-Write, replikasi sinkron/asinkron.
VM layanan menyediakan akses ke antarmuka manajemen WEB subsistem HyperFlex. Ada integrasi dengan vCenter, dan sebagian besar tugas sehari-hari dapat dilakukan darinya, tetapi penyimpanan data, misalnya, lebih mudah dipotong dari webcam terpisah jika Anda telah beralih ke antarmuka HTML5 yang cepat, atau menggunakan klien Flash yang lengkap dengan integrasi penuh. Di webcam layanan Anda dapat melihat kinerja dan status rinci sistem.
Ada jenis node lain dalam sebuah cluster - node komputasi. Ini bisa berupa server rak atau blade tanpa disk internal. Server ini dapat menjalankan VM yang datanya disimpan di server dengan disk. Dari sudut pandang akses data, tidak ada perbedaan antar tipe node, karena arsitekturnya melibatkan abstraksi dari lokasi fisik data. Rasio maksimum node komputasi dan node penyimpanan adalah 2:1.
Penggunaan node komputasi meningkatkan fleksibilitas saat menskalakan sumber daya cluster: kita tidak perlu membeli node tambahan dengan disk jika kita hanya membutuhkan CPU/RAM. Selain itu, kita dapat menambahkan sangkar blade dan menghemat penempatan rak server.
Hasilnya, kami memiliki platform hyperconverged dengan fitur-fitur berikut:
- Hingga 64 node dalam satu cluster (hingga 32 node penyimpanan).
- Jumlah minimum node dalam sebuah cluster adalah tiga (dua untuk cluster Edge).
- Mekanisme redundansi data: mirroring dengan faktor replikasi 2 dan 3.
- Klaster Metro.
- Replikasi VM asinkron ke kluster HyperFlex lain.
- Orkestrasi peralihan VM ke pusat data jarak jauh.
- Snapshot asli menggunakan teknologi Redirect-on-Write.
- Hingga 1 PB ruang yang dapat digunakan pada faktor replikasi 3 dan tanpa deduplikasi. Kami tidak memperhitungkan faktor replikasi 2 karena ini bukan pilihan untuk penjualan serius.
Nilai tambah besar lainnya adalah kemudahan pengelolaan dan penerapan. Semua kerumitan pengaturan server UCS ditangani oleh VM khusus yang disiapkan oleh para insinyur Cisco.
Konfigurasi bangku tes:
- 2 x Cisco UCS Fabric Interconnect 6248UP sebagai cluster manajemen dan komponen jaringan (48 port beroperasi dalam mode Ethernet 10G/FC 16G).
- Empat 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/peringkat ganda/x4/1.2v
jaringan
UCSC-MLOM-CSC-02 (VIC 1227). 2 port Ethernet 10G
Penyimpanan HBA
Cisco 12G Modular SAS Melewati Pengontrol
Disk Penyimpanan
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Opsi konfigurasi lainnyaSelain perangkat keras yang dipilih, opsi berikut saat ini tersedia:
- HXAF240c M5.
- Satu atau dua CPU mulai dari Intel Silver 4110 hingga Intel Platinum I8260Y. Generasi kedua tersedia.
- 24 slot memori, strip dari 16 GB RDIMM 2600 hingga 128 GB LRDIMM 2933.
- Dari 6 hingga 23 disk data, satu disk caching, satu disk sistem, dan satu disk boot.
Penggerak Kapasitas
- HX-SD960G61X-EV 960GB 2.5 Inci Nilai Perusahaan 6G SATA SSD (1X daya tahan) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2.5 inci Nilai Perusahaan 6G SATA SSD (1X daya tahan) SAS 3.8 TB.
- Caching Drive
- HX-NVMEXPB-I375 375GB 2.5 inci Intel Optane Drive, Performa & Daya Tahan Ekstrim.
- HX-NVMEHW-H1600* 1.6TB 2.5 inci Ent. Kinerja. NVMe SSD (daya tahan 3X) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 inci Ent. Kinerja. SSD SAS 12G (daya tahan 10X) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 inci Ent. Kinerja. 12G SAS SED SSD (daya tahan 10X) SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 inci Kinerja perusahaan 12G SAS SSD (daya tahan 3X).
Drive Sistem/Log
- HX-SD240GM1X-EV 240GB 2.5 inci Nilai Perusahaan 6G SATA SSD (Memerlukan peningkatan).
Boot Drive
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.
Terhubung ke jaringan melalui port Ethernet 40G, 25G, atau 10G.
FI dapat berupa HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Tes itu sendiri
Untuk menguji subsistem disk, saya menggunakan HCIBench 2.2.1. Ini adalah utilitas gratis yang memungkinkan Anda mengotomatiskan pembuatan beban dari beberapa mesin virtual. Beban itu sendiri dihasilkan oleh fio biasa.
Cluster kami terdiri dari empat node, faktor replikasi 3, semua disk adalah Flash.
Untuk pengujian, saya membuat empat penyimpanan data dan delapan mesin virtual. Untuk pengujian tulis, diasumsikan disk caching tidak penuh.
Hasil tesnya adalah sebagai berikut:
100% Baca 100% Acak
0% Baca 100% Acak
Kedalaman blok/antrian
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 mdtk 213804 IOPS
0,84 mdtk 303540 IOPS
1,36 md 374348 IOPS
2.47 mdtk 414116 IOPS
4,86 md 420180 IOPS
2,22 mdtk 57408 IOPS
3,09 mdtk 82744 IOPS
5,02 mdtk 101824 IPO
8,75 mdtk 116912 IOPS
17,2 mdtk 118592 IOPS
8K
0,67 mdtk 188416 IOPS
0,93 mdtk 273280 IOPS
1,7 mdtk 299932 IOPS
2,72 mdtk 376,484 IOPS
5,47 mdtk 373,176 IOPS
3,1 mdtk 41148 IOPS
4,7 mdtk 54396 IOPS
7,09 mdtk 72192 IOPS
12,77 mdtk 80132 IOPS
16K
0,77 mdtk 164116 IOPS
1,12 mdtk 228328 IOPS
1,9 mdtk 268140 IOPS
3,96 mdtk 258480 IOPS
3,8 mdtk 33640 IOPS
6,97 mdtk 36696 IOPS
11,35 mdtk 45060 IOPS
32K
1,07 mdtk 119292 IOPS
1,79 mdtk 142888 IOPS
3,56 mdtk 143760 IOPS
7,17 mdtk 17810 IOPS
11,96 mdtk 21396 IOPS
64K
1,84 mdtk 69440 IOPS
3,6 mdtk 71008 IOPS
7,26 mdtk 70404 IOPS
11,37 mdtk 11248 IOPS
Huruf tebal menunjukkan nilai yang setelahnya tidak ada peningkatan produktivitas, bahkan terkadang terlihat penurunan. Hal ini disebabkan oleh fakta bahwa kita dibatasi oleh kinerja jaringan/pengontrol/disk.
- Pembacaan berurutan 4432 MB/s.
- Tulis berurutan 804 MB/s.
- Jika salah satu pengontrol gagal (kegagalan mesin virtual atau host), penurunan kinerja menjadi dua kali lipat.
- Jika disk penyimpanan gagal, penarikannya adalah 1/3. Pembangunan kembali disk membutuhkan 5% sumber daya setiap pengontrol.
Pada blok kecil, kita dibatasi oleh kinerja pengontrol (mesin virtual), CPU-nya dimuat 100%, dan ketika blok bertambah, kita dibatasi oleh bandwidth port. 10 Gbps tidak cukup untuk membuka potensi sistem AllFlash. Sayangnya, parameter dari demo stand yang disediakan tidak memungkinkan kami untuk menguji operasi pada 40 Gbit/s.
Menurut kesan saya dari pengujian dan mempelajari arsitektur, karena algoritma yang menempatkan data di antara semua host, kami mendapatkan kinerja yang terukur dan dapat diprediksi, tetapi ini juga merupakan batasan saat membaca, karena dimungkinkan untuk memeras lebih banyak dari disk lokal, di sini mungkin menghemat jaringan yang lebih produktif, misalnya, tersedia FI pada 40 Gbit/s.
Selain itu, satu disk untuk caching dan deduplikasi mungkin menjadi batasan; pada kenyataannya, dalam pengujian ini kita dapat menulis ke empat disk SSD. Akan sangat bagus jika bisa meningkatkan jumlah drive caching dan melihat perbedaannya.
Penggunaan nyata
Untuk mengatur pusat data cadangan, Anda dapat menggunakan dua pendekatan (kami tidak mempertimbangkan untuk menempatkan cadangan di situs jarak jauh):
- Aktif pasif. Semua aplikasi dihosting di pusat data utama. Replikasi bersifat sinkron atau asinkron. Jika pusat data utama gagal, kita perlu mengaktifkan pusat data cadangan. Ini dapat dilakukan secara manual/skrip/aplikasi orkestrasi. Di sini kita akan mendapatkan RPO yang sepadan dengan frekuensi replikasi, dan RTO bergantung pada reaksi dan keterampilan administrator serta kualitas pengembangan/debugging dari rencana peralihan.
- Aktif-Aktif. Dalam hal ini, hanya ada replikasi sinkron; ketersediaan pusat data ditentukan oleh kuorum/arbiter yang berlokasi di situs ketiga. RPO = 0, dan RTO dapat mencapai 0 (jika aplikasi mengizinkan) atau sama dengan waktu failover suatu node dalam cluster virtualisasi. Pada tingkat virtualisasi, dibuat cluster yang membentang (Metro) yang memerlukan penyimpanan Aktif-Aktif.
Biasanya kami melihat klien sudah mengimplementasikan arsitektur dengan sistem penyimpanan klasik di pusat data utama, jadi kami merancang yang lain untuk direplikasi. Seperti yang saya sebutkan, Cisco HyperFlex menawarkan replikasi asinkron dan pembuatan cluster virtualisasi yang diperluas. Pada saat yang sama, kita tidak memerlukan sistem penyimpanan khusus tingkat Menengah dan lebih tinggi dengan fungsi replikasi yang mahal dan akses data Aktif-Aktif pada dua sistem penyimpanan.
Skenario 1: Kami memiliki pusat data utama dan cadangan, platform virtualisasi di VMware vSphere. Semua sistem produktif ditempatkan di pusat data utama, dan replikasi mesin virtual dilakukan di tingkat hypervisor, hal ini akan menghindari VM tetap aktif di pusat data cadangan. Kami mereplikasi database dan aplikasi khusus menggunakan alat bawaan dan menjaga VM tetap aktif. Jika pusat data utama gagal, kami meluncurkan sistem di pusat data cadangan. Kami yakin kami memiliki sekitar 100 mesin virtual. Saat pusat data utama beroperasi, pusat data siaga dapat menjalankan lingkungan pengujian dan sistem lain yang dapat dimatikan jika pusat data utama dialihkan. Mungkin juga kita menggunakan replikasi dua arah. Dari sudut pandang perangkat keras, tidak ada yang berubah.
Dalam kasus arsitektur klasik, kami akan memasang sistem penyimpanan hibrid di setiap pusat data dengan akses melalui FibreChannel, tiering, deduplikasi, dan kompresi (tetapi tidak online), 8 server untuk setiap situs, 2 sakelar FibreChannel, dan 10G Ethernet. Untuk manajemen replikasi dan peralihan dalam arsitektur klasik, kita dapat menggunakan alat VMware (Replikasi + SRM) atau alat pihak ketiga, yang akan sedikit lebih murah dan terkadang lebih nyaman.
Gambar tersebut menunjukkan diagram.
Saat menggunakan Cisco HyperFlex, arsitektur berikut diperoleh:
Untuk HyperFlex, saya menggunakan server dengan sumber daya CPU/RAM yang besar, karena... Beberapa sumber daya akan masuk ke VM pengontrol HyperFlex; dalam hal CPU dan memori, saya bahkan sedikit mengkonfigurasi ulang konfigurasi HyperFlex agar tidak bermain-main dengan Cisco dan menjamin sumber daya untuk VM yang tersisa. Tapi kita bisa mengabaikan switch FibreChannel, dan kita tidak memerlukan port Ethernet untuk setiap server; lalu lintas lokal dialihkan dalam FI.
Hasilnya adalah konfigurasi berikut untuk setiap pusat data:
Server
Server 8 x 1U (RAM 384 GB, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (RAM 512 GB, 2 x Intel Gold 6150, SSD 3,2 GB, NL-SAS 10 x 6 TB)
SHD
Sistem penyimpanan hibrid dengan FC Front-End (SSD 20 TB, NL-SAS 130 TB)
-
LAN
2 x sakelar Ethernet 10G 12 port
-
SAN
2 x sakelar FC 32/16Gb 24 port
2 x Cisco UCS FI 6332
Lisensi
VMware Ent Plus
Replikasi dan/atau orkestrasi peralihan VM
VMware Ent Plus
Saya tidak memberikan lisensi perangkat lunak replikasi untuk Hyperflex, karena ini sudah tersedia untuk kami.
Untuk arsitektur klasik, saya memilih vendor yang telah memantapkan dirinya sebagai produsen berkualitas tinggi dan murah. Untuk kedua opsi tersebut, saya menerapkan diskon standar untuk solusi tertentu, dan sebagai hasilnya saya menerima harga sebenarnya.
Solusi Cisco HyperFlex ternyata 13% lebih murah.
Skenario 2: pembuatan dua pusat data aktif. Dalam skenario ini, kami merancang cluster yang diperluas di VMware.
Arsitektur klasik terdiri dari server virtualisasi, SAN (protokol FC) dan dua sistem penyimpanan yang dapat membaca dan menulis hingga volume yang terbentang di antara keduanya. Pada setiap sistem penyimpanan kami menempatkan kapasitas yang berguna untuk penyimpanan.
Di HyperFlex kita cukup membuat Stretch Cluster dengan jumlah node yang sama di kedua situs. Dalam hal ini, faktor replikasi 2+2 digunakan.
Hasilnya adalah konfigurasi berikut:
arsitektur klasik
HiperFlex
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 Gold 6132, NVMe 1,6 TB, SSD 12 x 3,8 TB, VIC 1387)
SHD
2 x sistem penyimpanan AllFlash (SSD 150 TB)
-
LAN
4 x sakelar Ethernet 10G 24 port
-
SAN
4 x sakelar FC 32/16Gb 24 port
4 x Cisco UCS FI 6332
Lisensi
VMware Ent Plus
VMware Ent Plus
Dalam semua perhitungan, saya tidak memperhitungkan infrastruktur jaringan, biaya pusat data, dll.: semuanya akan sama untuk arsitektur klasik dan untuk solusi HyperFlex.
Dari segi biaya, HyperFlex ternyata lebih mahal 5%. Perlu dicatat di sini bahwa dalam hal sumber daya CPU/RAM, saya memiliki kecenderungan untuk Cisco, karena dalam konfigurasi saya mengisi saluran pengontrol memori secara merata. Biayanya sedikit lebih tinggi, namun tidak dalam urutan besarnya, yang secara jelas menunjukkan bahwa hiperkonvergensi belum tentu merupakan “mainan bagi orang kaya”, namun dapat bersaing dengan pendekatan standar dalam membangun pusat data. Ini mungkin juga menarik bagi mereka yang sudah memiliki server Cisco UCS dan infrastruktur yang sesuai untuk server tersebut.
Di antara keuntungannya, kami mendapatkan tidak adanya biaya untuk mengelola SAN dan sistem penyimpanan, kompresi online dan deduplikasi, satu titik masuk untuk dukungan (virtualisasi, server, juga sistem penyimpanan), menghemat ruang (tetapi tidak di semua skenario), menyederhanakan operasi.
Sedangkan untuk dukungan, di sini Anda mendapatkannya dari satu vendor - Cisco. Dilihat dari pengalaman saya dengan server Cisco UCS, saya menyukainya; saya tidak perlu membukanya di HyperFlex, semuanya bekerja sama saja. Insinyur merespons dengan cepat dan tidak hanya dapat memecahkan masalah umum, tetapi juga kasus-kasus rumit. Kadang-kadang saya menoleh ke mereka dengan pertanyaan: "Apakah mungkin melakukan ini, kencangkan?" atau “Saya mengonfigurasi sesuatu di sini, dan tidak berfungsi. Membantu!" - mereka akan dengan sabar menemukan panduan yang diperlukan di sana dan menunjukkan tindakan yang benar; mereka tidak akan menjawab: "Kami hanya menyelesaikan masalah perangkat keras."
referensi
- surat saya - [email dilindungi]
Sumber: www.habr.com