Hasil yang ingin Anda capai, dan cara Anda memutuskan untuk melakukannya, adalah hal yang sangat berbeda. Terus terang, apa yang ingin Anda terapkan adalah ide yang buruk, dan jika Anda entah bagaimana bisa membuatnya bekerja, itu tidak akan bekerja untuk waktu yang lama (atau sangat baik).
Apa yang membuat pertanyaan ini sulit dijawab adalah bahwa Anda telah melompat langsung ke implementasi, dan belum menggambarkan sesuatu yang berguna tentang lingkungan Anda atau apa yang Anda coba untuk benar-benar capai. Tolong jangan lakukan itu, Anda akan mendapatkan hasil yang jauh lebih baik di sini jika Anda "menunjukkan pekerjaan Anda".
Biarkan saya mengajukan beberapa skenario, untuk memberi Anda gambaran tentang apa yang mungkin, praktis, dan berguna:
- Memastikan tidak ada email yang hilang: (Saya rasa ini bukan yang Anda butuhkan, karena dokumentasi yang Anda rujuk mencukupi) Semua yang Anda ingin miliki di sini adalah kepastian bahwa terlepas dari berapa lama pengiriman email dan infrastruktur manajemen Anda turun, Anda tidak akan bouncing email apa pun, dan Anda dapat mengontrol kapan pengiriman dilakukan. Untuk ini, cadangan MX luar-situs "sederhana" akan berfungsi dengan baik. Saya katakan "sederhana" karena Anda perlu mereplikasi banyak data ke cadangan (semua logika anti-spam, informasi pengguna / alias yang valid sehingga Anda dapat memantulkan surat yang tidak valid pada waktu SMTP, hal semacam itu), tetapi semuanya dapat skrip , automatable, dan cukup mudah diterapkan dengan sedikit perawatan. Selama Anda punya cukup disk untuk mengantri semua email,
- Memastikan ketersediaan sistem email lengkap : Sepertinya ini yang Anda inginkan, tetapi tidak sederhana atau cantik. Pada dasarnya, Anda ingin dapat memberikan layanan email "penuh" kepada pengguna Anda jika terjadi kegagalan situs yang lengkap. Pada prinsipnya, ini sebenarnya tidak mungkin, karena replikasi tidak instan, tetapi Anda bisa mencapai tingkat keandalan yang masuk akal setidaknya. Bagian yang sulit bukanlah MTA; itu toko surat itu sendiri. Anda harus mengetahui cara mereplikasi semua operasi penyimpanan email (pengiriman email baru, perubahan status pesan, penghapusan) ke situs kedua dalam waktu hampir bersamaan - dan melakukannya dengan dua cara, tergantung pada situs mana yang ditayangkan. . Anda dapat mengambil opsi murah, dari rsync berkala (dengan risiko bahwa apa pun dilakukan sejak rsync terakhir hilang selamanyajika Anda perlu failover), atau gunakan berbagai teknik replikasi tingkat file atau blok untuk mencoba dan menjaga semuanya tetap sinkron dalam waktu yang hampir bersamaan (mengurangi jumlah data yang hilang dengan imbalan konfigurasi dan operasi yang jauh lebih rumit) . Beberapa sistem email memiliki dukungan untuk semacam replikasi bawaan, yang dapat membuat hidup lebih mudah. Lalu ada seluruh masalah gagal, dan bagaimana Anda melakukannya, dan kemudian gagal kembali , yang lebih sulit lagi, dan akhirnya Anda harus mengujinya secara berkala, untuk memastikan bahwa peningkatan OS yang Anda lakukan beberapa waktu lalu tidak hancurkan apapun ...
Pada dasarnya, opsi terakhir menyakitkan dan menjengkelkan. Preferensi pribadi saya, jika Anda bisa lolos begitu saja (dan Anda akan terkejut betapa seringnya Anda bisa) adalah meletakkan semua telur Anda dalam satu keranjang, setelah memastikan Anda memiliki keranjang yang benar-benar bagus dan kokoh (rekayasa sistem yang tepat ), menyimpan stok keranjang-keranjang dan alat-alat di tangan (fokus pada High Recoverability ), dan memastikan bahwa orang-orang tahu bahwa sesekali, beberapa telur mungkin pecah dan Anda benar-benar minta maaf tetapi hidup ini tidak sempurna (jangan membuat jaminan SLA yang tidak masuk akal).
Ada saat-saat ketika Anda membutuhkan ketersediaan sangat tinggi, dan saya telah membangun sistem yang memastikannya, tetapi mereka tidak sederhana, dan dalam banyak kasus mereka tidak hemat biaya, itulah tujuan kami di sini. Ya, HA itu keren dan seksi, dan Anda mendapat pujian dari geek untuk membangun beberapa kompleksitas yang menjulang tinggi, tapi kami di sini bukan untuk mengelus ego kami. Kami di sini untuk memberikan nilai bisnis, dan saya minta maaf, tetapi cluster surat multi-situs Rube Goldberg yang sangat tersedia sepertinya tidak akan memberikan nilai sebanyak layanan surat sederhana, tangguh, dan sesekali "kami" Maaf atas pemadaman surat, kami akan memiliki sistem kembali dalam satu jam, jangan ragu untuk minum kopi dan muffin pada kami "pengumuman.