Yatayda Büyüme (200.000 e-posta/gün üzeri)
Tek bir DeepFilter sunucusu günde 200.000 e-postaya kadar olan trafik için önerilir. Gerçek kapasite donanıma ve trafik profiline göre değişir. Bu hacmin üzerinde kalıcı olarak çalışan kurumlarda tercih edilen yöntem, tek sunucuyu büyütmek yerine birden fazla bağımsız DeepFilter sunucusu kurup gelen yükü bunlara dağıtmaktır. Bu sayfa, yatayda büyümenin nasıl kurgulandığını ve nelerin kapsam dışında olduğunu anlatır.
Yatayda büyüme bir yük dağıtımı yöntemidir; yüksek erişilebilirlik çözümü değildir. Sunucular arasında ortak durum bilgisi, otomatik devralma veya birbirini yedekleme mekanizması bulunmaz. Bir sunucu devre dışı kaldığında o sunucuya düşmüş kayıtlara erişilemez; yalnızca gönderen tarafın yeniden deneme davranışı devreye girer.
Ne zaman gerekir
Yatayda büyümeyi şu durumlarda değerlendirin:
| Durum | Değerlendirme |
|---|---|
| Günlük e-posta hacmi 200.000'in altında | Tek sunucu yeterlidir, ikinci sunucuya gerek yoktur |
| Günlük hacim kalıcı olarak 200.000 üzerinde | Yükü ikinci bir sunucuya bölün |
| Kısa süreli kampanya/sezon yoğunluğu | Önce donanım kaynaklarını (CPU, RAM, disk) gözden geçirin |
| Farklı lokasyonlarda ayrı e-posta altyapısı | Her lokasyon için ayrı sunucu doğal bir tercihtir |
Hacim artışına karar vermeden önce disk planını da güncelleyin: her 10.000 günlük e-posta için yıllık log saklama amacıyla en az 50 GB ek disk gerekir. Bu hesap her sunucu için ayrı ayrı, o sunucuya düşecek pay üzerinden yapılır.
Nasıl çalışır
Yöntem, SMTP protokolünün kendi davranışına dayanır. Bir alan adı için birden fazla MX kaydı aynı öncelik değeriyle tanımlandığında, gönderen e-posta sunucuları bu adresler arasından seçim yapar ve trafik zamanla kabaca eşit dağılır. Ek bir yük dengeleyici cihaza veya yazılıma ihtiyaç yoktur.
Kurgu üç adımdan oluşur:
- Sunucuları kurun. Her sunucuyu tek sunucu kurulumundaki adımların aynısıyla, sıfırdan kurun. Her birinin kendi sunucu adı, kendi IP adresi ve kendi kurulum sihirbazı vardır.
- DNS kayıtlarını yazın. Her sunucu için ayrı bir A kaydı oluşturun ve MX kayıtlarını eşit öncelikle tanımlayın. Her IP için ayrı PTR kaydı talep edin ve SPF kaydınıza tüm sunucu IP adreslerini ekleyin.
- Aynı yapılandırmayı her sunucuda tekrarlayın. Alan adı tanımları, teslim hedefi, engelleme/izin listeleri ve tarama tercihleri her sunucunun kendi panelinde ayrı ayrı girilir.
Örnek DNS kurgusu:
mail1.alanadi.com. IN A 203.0.113.10
mail2.alanadi.com. IN A 203.0.113.11
alanadi.com. IN MX 10 mail1.alanadi.com.
alanadi.com. IN MX 10 mail2.alanadi.com.
alanadi.com. IN TXT "v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 ~all"
Öncelik değerlerini farklı verirseniz (örneğin 10 ve 20) yük dağılmaz; düşük değerli sunucu tüm trafiği alır, diğeri yalnızca ilki yanıt vermediğinde denenir. Dağıtım isteniyorsa değerler eşit olmalıdır.
Sınırlar
Bu maddeler tasarım gereğidir ve yapılandırmayla değiştirilemez. Devreye almadan önce kurumunuz açısından kabul edilebilir olduklarını doğrulayın.
| Konu | Davranış |
|---|---|
| Lisans | Her sunucu ayrı lisans gerektirir |
| Karantina | Paylaşılmaz. Bir e-posta hangi sunucuya düştüyse orada karantinaya girer |
| Karantina saklama süresi | Her sunucuda ayrı işler; varsayılan 30 gün sonra e-posta otomatik silinir |
| Kullanıcı digest'i | Kullanıcı, karantina bildirimini e-postayı işleyen sunucudan alır |
| Son kullanıcı portalı | Kullanıcı, karantinadaki bir e-postayı görmek için o e-postayı işleyen sunucunun portalına girer |
| Yönetim | Her sunucunun kendi yönetim paneli vardır; ayarlar her birinde ayrı yapılır |
| Raporlar ve analitik | Her sunucu yalnızca kendi trafiğini raporlar; birleşik görünüm yoktur |
| Yedekleme | Her sunucunun yedeği ayrı alınır ve ayrı geri yüklenir |
| Devralma | Sunucular arasında otomatik devralma veya durum paylaşımı yoktur |
Karantinanın paylaşılmaması pratikte şu anlama gelir: bir kullanıcı iki farklı sunucudan karantina bildirimi alabilir ve serbest bırakma işlemini ilgili bildirimin geldiği portal üzerinden yapar. Kullanıcılarınızı bu konuda önceden bilgilendirin.
Karantinadaki e-postalar süresiz saklanmaz. Varsayılan saklama süresi 30 gündür; bu süre dolduğunda e-posta otomatik olarak silinir. Süre yönetim panelinden değiştirilebilir (en az 1 gün, üst sınır yoktur) ve her sunucuda ayrı ayrı ayarlanır. Sunucuların saklama sürelerini aynı değerde tutun; aksi hâlde kullanıcılar bir sunucuda hâlâ erişebildikleri bir e-postanın diğerinde silinmiş olmasıyla karşılaşır.
İşletim önerileri
- Ayar değişikliklerini tüm sunuculara aynı gün uygulayın. Sunucular arasındaki yapılandırma farkları, aynı gönderenin bir sunucuda geçip diğerinde karantinaya düşmesine yol açar.
- Sürüm güncellemelerini de her sunucuda ayrı ayrı yapın ve sürümleri aynı seviyede tutun.
- Her sunucunun IP adresi için ayrı ayrı itibar takibi yapın; bir IP'nin kara listeye girmesi yalnızca o sunucudan çıkan teslimatları etkiler.
- Sunucu ekleyip çıkardığınızda SPF kaydını ve PTR taleplerini güncellemeyi unutmayın.
Ağ, port ve DNS ayrıntıları için Ağ Gereksinimleri sayfasına bakın.