Praktik terbaik untuk topologi Exchange 2010 HA mempertimbangkan 6 x lisensi Exchange dan TMG 2010


8

Apa yang akan menjadi topologi terbaik mengingat:

  1. 6 x Pertukaran Lisensi Standar 2010
  2. 2 x Lokasi terpisah yang seharusnya mendukung redundansi jika terjadi masalah tautan
  3. 4 x Forefront TMG 2010 dengan Forefront Security dan Forefront Protection / Security

Beberapa lokasi di seluruh dunia menggunakan Exchange itu. Sebagian besar lokasi akan terhubung dengan VPN Tunnel (pasti yang menjadi tuan rumah Exchange).

Saya sedang memikirkan sesuatu seperti ini:

Lokasi MAIN (sekitar 70-100 orang):

  1. 2x TMG 2010 di NLB
  2. 1x Pertukaran 2010 Peran CAS / HUB
  3. 2x Peran Exchange Mail 2010 (Aktif + Pasif)

DUKUNGAN Lokasi (sekitar 20 orang):

  1. 2x TMG 2010 di NLB
  2. 1x Pertukaran 2010 Peran CAS / HUB
  3. 2x Peran Exchange Mail 2010 (Aktif + Pasif)

Manajemen ingin memastikan bahwa jika ada masalah di lokasi utama (kegagalan daya, kehilangan sambungan, dll.) Lokasi kedua dapat mendukung semua lalu lintas dari seluruh dunia dan sebaliknya. Kami memiliki 6-7 lokasi dan lebih banyak yang datang (bukan yang besar tetapi seperti 10+ orang per setiap lokasi).

Saya tahu bahwa CAS / HUB adalah satu-satunya titik kegagalan (dan tidak ada NLB), tetapi saya hanya kekurangan lisensi untuk melakukan redundansi.

Apa pendapat Anda tentang pendekatan ini? Apa pendekatan yang lebih baik menurut Anda?

Jawaban:


5

Pengaturan itu tidak terdengar terlalu konyol bagi saya, dan saya tidak akan banyak berubah. Saya berasumsi semua pekerjaan persiapan telah dilakukan (seperti beberapa Situs Direktori Aktif, pengontrol Domain di setiap situs, dll.) Jadi saya tidak akan membahas lebih detail tentang itu. Jika Anda dapat sedikit meregangkan anggaran Anda, saya akan sedikit mengubah topologi CAS Anda untuk menghilangkan SPOF.

Anda dapat menginstal peran Hub Transport di server Kotak Surat Anda dan mereka akan secara otomatis memuat saldo sendiri berdasarkan situs Active Directory tempat mereka berada. Itu adalah kemenangan cepat dan mudah, dan saya tidak dapat melihat bahwa banyak alasan untuk tidak melakukan ini .

Jika anggaran Anda dapat menampung 2 penyeimbang beban perangkat keras, Anda juga dapat menginstal peran CAS di server Kotak Surat. Anda kemudian akan membuat catatan A di DNS untuk penyeimbang beban Anda dan melakukan konfigurasi Database Kotak Surat yang sesuai di setiap situs untuk menggunakan Array CAS untuk situs tersebut.
Untuk melakukan ini, keluarkan perintah New-ClientAccessArray -Fqdn "ex-sitename-casarray.acme-widgets.com" -Site "AD-Site-MAIN"untuk setiap situs (mengganti catatan A Anda dan Nama Situs AD nyata yang sesuai).
Lalu masalah Set-MailboxDatabase "<<Appropriate Database>>" -RpcClientAccessServer <<site-casarray-name.acme-widgets.com>>untuk memastikan Database Kotak Surat Anda menggunakan CAS Array.

Cara terbaik adalah memiliki salinan lokal kotak surat pengguna di situs yang sama dengan pengguna, jadi saya akan membuat 2 Database kotak surat masing-masing mereplikasi ke server kotak surat di situs yang sama, serta situs lain (saya sudah melakukan diagram untuk memvisualisasikannya untuk Anda). Untuk pengguna di situs MAIN, tempatkan Kotak Surat mereka di DB Kotak Pesan Utama dan bagi pengguna di situs DUKUNGAN, tempatkan Kotak Surat mereka di DB Kotak Pesan Dukungan. teks alternatif


1
Saya tidak begitu yakin saya setuju dengan pernyataan Anda bahwa server kotak surat pengguna harus di situs yang sama. Ini mungkin benar 10 tahun yang lalu, tetapi semua versi Exchange mulai tahun 2003 mendukung mode cache. Gabungkan bahwa dengan sejumlah kecil pengguna di situs dukungan dan saya ragu ada orang yang akan melihat perbedaan. Yang terbaik adalah membuat database berdasarkan faktor selain lokasi fisik. Batas penyimpanan, tingkat klasifikasi, kebutuhan pengarsipan, atau tujuan waktu pemulihan semuanya lebih baik digunakan untuk memisahkan kotak surat menjadi basis data.
Jason Berg

Terima kasih atas komentar @Jason Berg, saya menghargai masukan Anda. Jika situs DUKUNGAN siap untuk menangani lalu lintas dari situs MAIN, saya menganggap tautan WAN akan cukup bagus, jadi ya, pengguna mungkin tidak akan melihat perbedaan. Alasan saya mengatakan itu sederhana, dan itu karena instruktur pada kursus pelatihan saya mengatakan untuk melakukan itu. Sejujurnya, itu lebih dari sekadar "ketika Anda membuat database kotak surat, letakkan di situs yang sama dengan pengguna" dan kemudian dia pindah ke yang lain. Itu tidak terdengar seperti saran bodoh, jadi aku tidak terlalu memikirkannya.
Ben Pilbrow

TMG 2010 (ISA baru) memiliki load balancing sehingga tidak akan menjadi masalah besar tetapi menempatkan setiap peran pada setiap kotak tampaknya agak berlebihan. Saya tahu peran CAS adalah SPOF dan tidak begitu yakin apa yang harus dilakukan dengan ini tanpa meletakkan semuanya dalam satu keranjang. Kami mendapatkan 6 lisensi dari kemitraan secara gratis dan kami harus membeli beberapa perangkat keras, ditambah beberapa CAL jadi saya tidak berpikir klien saya ingin membayar harga tambahan untuk itu. Tetapi saya akan memastikan untuk memasukkannya ke dalam dokumen untuk memastikan mereka memahami risikonya (downtime).
MadBoy

Jika TMG dapat memuat keseimbangan server CAS, itu hebat (saya tidak akan berpura-pura tahu apa-apa tentang TMG). Bisakah saya bertanya mengapa Anda tidak suka menempatkan semua peran di semua kotak, apakah Anda pikir akan ada hit kinerja besar? Tanpa berusaha terdengar seperti orang brengsek (saya benar-benar tidak ingin bertemu seperti itu), menurut pendapat saya tidak ada yang namanya berlebihan - Anda membuat solusi yang lebih berlebihan, yang setelah semua yang Anda cari. Bisakah Anda menyarankan untuk menempatkan Hub Transport tambahan pada 1 server Mailbox dan CAS di sisi lain untuk sedikit meringankannya? (Mengingat CAS masih perlu load balancing).
Ben Pilbrow

Saya bisa melakukannya juga 4 server di lokasi utama, dan 2 dengan semua peran di yang lain dengan penyeimbang beban. Ini dapat memberikan lokasi utama dengan buku-buku praktik terbaik dan lokasi dukungan dengan solusi lengkap.
MadBoy
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.