Kami mendapatkan sepasang switch 8Gb baru untuk kain saluran serat kami. Ini adalah Hal yang Baik karena kami kehabisan port di pusat data utama kami, dan itu akan memungkinkan kami untuk memiliki setidaknya satu 8Gb ISL yang berjalan di antara dua pusat data kami.
Dua pusat data kami berjarak sekitar 3,2 km saat serat berjalan. Kami telah mendapatkan layanan 4Gb yang solid selama beberapa tahun sekarang, dan saya sangat berharap ini dapat mempertahankan 8Gb juga.
Saat ini saya mencari tahu cara mengkonfigurasi ulang fabric kami untuk menerima switch baru ini. Karena keputusan biaya beberapa tahun yang lalu kami tidak menjalankan fabric loop ganda yang sepenuhnya terpisah. Biaya redundansi penuh dipandang sebagai lebih mahal daripada downtime kegagalan saklar yang tidak mungkin. Keputusan itu dibuat sebelum waktu saya, dan sejak itu banyak hal tidak membaik.
Saya ingin mengambil kesempatan ini untuk membuat kain kami lebih tangguh dalam menghadapi kegagalan sakelar (atau pemutakhiran FabricOS).
Berikut adalah diagram dari apa yang saya pikirkan untuk lay-out. Item biru adalah item baru, item merah adalah tautan yang ada yang akan (kembali) dipindahkan.
(sumber: sysadmin1138.net )
Garis panah merah adalah link switch ISL saat ini, kedua ISL berasal dari switch yang sama. EVA6100 saat ini terhubung ke kedua 16/4 switch yang memiliki ISL. Sakelar baru akan memungkinkan kami memiliki dua sakelar di DC jarak jauh, salah satu dari ISL jarak jauh pindah ke sakelar baru.
Keuntungan dari hal ini adalah bahwa setiap switch tidak lebih dari 2 hop dari switch lain, dan kedua EVA4400, yang akan berada dalam hubungan replikasi EVA, berjarak 1 hop dari satu sama lain. EVA6100 dalam bagan adalah perangkat yang lebih tua yang pada akhirnya akan diganti, mungkin dengan EVA4400 lainnya.
Bagian bawah bagan adalah tempat sebagian besar server kami berada, dan saya memiliki beberapa kekhawatiran tentang penempatan yang tepat. Apa yang perlu masuk ke sana:
- 10 host VMWare ESX4.1
- Mengakses sumber daya pada EVA6100
- 4 server Windows Server 2008 dalam satu kluster kegagalan (kluster file server)
- Mengakses sumber daya pada EVA6100 dan EVA4400 jarak jauh
- 2 server Windows Server 2008 dalam cluster fail-over kedua (konten Blackboard)
- Mengakses sumber daya pada EVA6100
- 2 server basis data MS-SQL
- Mengakses sumber daya pada EVA6100, dengan ekspor DB malam hari ke EVA4400
- 1 perpustakaan tape LTO4 dengan 2 drive tape LTO4. Setiap drive mendapatkan port seratnya sendiri.
- Server cadangan (tidak ada dalam daftar ini) menggulung mereka
Saat ini ESX cluster dapat mentolerir hingga 3, mungkin 4, host turun sebelum kita harus mulai mematikan VM untuk ruang. Untungnya, semuanya telah dihidupkan MPIO.
Tautan 4Gb ISL saat ini belum mendekati kejenuhan yang saya perhatikan. Itu mungkin berubah dengan dua mereplikasi EVA4400, tetapi setidaknya salah satu ISL akan menjadi 8Gb. Melihat kinerja yang saya dapatkan dari EVA4400-A Saya sangat yakin bahwa bahkan dengan lalu lintas replikasi kita akan mengalami kesulitan melintasi garis 4Gb.
Cluster penyajian file 4-simpul dapat memiliki dua node pada SAN1SW4 dan dua pada SAN1SW1, karena itu akan membuat kedua array penyimpanan hanya satu hop.
10 ESX node saya agak jengkel. Tiga di SAN1SW4, tiga di SAN1SW2, dan empat di SAN1SW1 adalah sebuah pilihan, dan saya akan sangat tertarik untuk mendengar pendapat lain tentang tata letak. Sebagian besar memiliki kartu FC dual-port, jadi saya dapat menjalankan beberapa node beberapa kali. Tidak semuanya , tetapi cukup untuk memungkinkan satu saklar gagal tanpa membunuh semuanya.
Dua kotak MS-SQL harus menggunakan SAN1SW3 dan SAN1SW2, karena mereka harus dekat dengan penyimpanan utama mereka dan kinerja db-ekspor kurang penting.
Drive LTO4 saat ini menggunakan SW2 dan 2 hop dari streamer utama mereka, jadi saya sudah tahu cara kerjanya. Itu bisa tetap di SW2 dan SW3.
Saya lebih suka untuk tidak menjadikan separuh bawah bagan sebagai topologi yang sepenuhnya terhubung karena hal itu akan mengurangi jumlah port yang dapat digunakan dari 66 menjadi 62, dan SAN1SW1 akan menjadi 25% ISL. Tetapi jika itu sangat disarankan saya bisa pergi ke rute itu.
Pembaruan: Beberapa angka kinerja yang mungkin akan berguna. Saya sudah memilikinya, saya hanya berjarak bahwa mereka berguna untuk masalah seperti ini.
EVA4400-A pada grafik di atas melakukan hal berikut:
- Selama hari kerja:
- Rata-rata I / O ops di bawah 1000 dengan paku hingga 4.500 selama snapshot file-server cluster ShadowCopy (berlangsung sekitar 15-30 detik).
- MB / s umumnya tetap dalam kisaran 10-30MB, dengan lonjakan hingga 70MB dan 200MB selama ShadowCopies.
- Pada malam hari (cadangan) adalah saat pedal benar-benar cepat:
- I / O ops rata-rata sekitar 1500, dengan lonjakan hingga 5.500 selama backup DB.
- MB / s sangat bervariasi, tetapi berjalan sekitar 100MB selama beberapa jam, dan memompa 300MB / s mengesankan selama sekitar 15 menit selama proses ekspor SQL.
EVA6100 jauh lebih sibuk, karena merupakan rumah bagi gugus ESX, MSSQL, dan seluruh lingkungan Exchange 2007.
- Pada siang hari rata-rata I / O beroperasi sekitar 2000 dengan lonjakan yang sering hingga sekitar 5000 (lebih banyak proses basis data), dan MB / s rata-rata antara 20-50MB / s. MB Puncak / s terjadi selama snapshot ShadowCopy pada kluster penyajian file (~ 240MB / s) dan berlangsung kurang dari satu menit.
- Pada malam hari, Exchange Online Defrag yang beroperasi dari jam 1 pagi hingga 5 pagi memompa I / O Ops ke saluran di 7800 (mendekati kecepatan sisi untuk akses acak dengan jumlah spindel ini) dan 70MB / s.
Saya sangat menghargai saran yang Anda miliki.
