HAProxy'de Tek Portta Katman 4 ve Katman 7 Trafik Dağıtımı

Sesli Dinle — Makale

HAProxy, tek bir IP adresindeki dinleme portuna gelen bağlantıları birden fazla backend sunucusuna aktarabilir. HAProxy'nin trafiği nasıl dağıtacağı, yapılandırmada seçilen çalışma moduna bağlıdır: Katman 4 için mode tcp, Katman 7 için mode http kullanılır.

Katman 4 modeli TCP bağlantısını bir bütün olarak seçilen sunucuya taşır. Katman 7 modeli ise HTTP isteğini analiz ederek Host alanı, URL yolu, yöntem veya başka HTTP verilerine göre farklı backend havuzları seçebilir.

Tek port kullanmak, birbirinden bağımsız her protokolün otomatik olarak ayrıştırılabileceği anlamına gelmez. Aynı hizmetin birden fazla sunucuya dağıtılması ile farklı hizmetlerin trafik içeriğine bakılarak ayrılması, ayrı mimari ihtiyaçlardır.

Tek Portta Katman 4 ve Katman 7 Seçimi

• Temel TCP dağıtımında HAProxy, bağlantıyı bir bütün olarak backend sunucusuna aktarır; HTTP isteğine göre işlem yapılacaksa uygun içerik inceleme veya mod geçişi kuralları ayrıca gerekir.
• mode http ayarı, HTTP isteklerini ayrıştırarak Host, URL yolu ve başlık alanlarına göre backend seçebilir.
• TLS passthrough modelinde trafik backend'e kadar şifreli kalır; HTTP Host ve yol bilgisi HAProxy tarafından görülemez.
• TLS sonlandırmada HAProxy şifreli trafiği çözer; HTTP tabanlı yönlendirme, ayrıntılı günlükleme ve uygulama sağlık kontrolü yapılabilir.
• Protokol, TLS anahtarlarının tutulacağı yer, günlük gereksinimi, oturum sürekliliği ve hata davranışı Katman 4 ile Katman 7 seçimini birlikte belirler.

HAProxy'de Frontend, Backend ve ACL ile Trafik Yönlendirme

HAProxy yapılandırması, istemciden bağlantı kabul eden frontend bölümü ile trafiğin gönderileceği backend havuzunu birbirinden ayırır. Böylece dinleme noktası değişmeden sunucu havuzları ve yönlendirme kuralları yönetilebilir.

Frontend ve Bind Ayarı

Frontend, istemci bağlantılarının kabul edildiği dinleme bölümüdür. bind ifadesi, HAProxy'nin hangi IP adresini ve portu dinleyeceğini belirler; örneğin tüm uygun yerel adreslerde 443 numaralı portu dinlemek bu bölümde tanımlanır.

Frontend içindeki mode ayarı temel işleme biçimini belirler. HTTP modundaki bir frontend'de TCP bağlantı kuralları da kullanılabilir; mode http seçimi bütün TCP kurallarını devre dışı bırakmaz.

TCP modundaki bir frontend, uygun HTTP backend'ine yönlendirme yaparak HTTP işlemeye geçebilir. HAProxy 2.4 ve sonrasında tcp-request content switch-mode http kuralı bu geçişi frontend içinde de yapabilir. Geçiş koşulu, içerik inceleme süresi ve HTTP olmayan trafik için uygulanacak davranış açıkça tanımlanmalıdır; şifreli HTTPS trafiği, TLS çözülmeden HTTP olarak ayrıştırılamaz.

Backend Sunucu Havuzu

Backend, HAProxy'nin bağlantı kurabileceği arka uç sunucularını içerir. Her sunucu için adres, port, ağırlık ve sağlık kontrolü gibi ayarlar tanımlanabilir. Yük dağıtım algoritması da genellikle bu bölümde seçilir.

Aynı uygulamanın birden fazla örneği aynı backend içinde tutulabilir. Bir sunucu sağlık kontrolünü geçemediğinde HAProxy, yapılandırmaya bağlı olarak yeni bağlantıları sağlıklı kalan sunuculara göndermeye devam eder.

ACL ile Backend Seçimi

ACL, istemci adresi, TLS el sıkışmasındaki SNI (Server Name Indication), HTTP Host alanı, URL yolu veya başka erişilebilir veriler üzerinde eşleşme koşulu tanımlar. use_backend, bu koşul sağlandığında seçilecek backend'i belirtir.

use_backend kuralları yazıldıkları sırayla değerlendirilir ve ilk eşleşen kural backend seçimini yapar. Hiçbir koşul eşleşmezse default_backend devreye girer. Bu nedenle genel kuralların özel kurallardan önce yazılması, beklenmeyen yönlendirmelere neden olabilir.

Katman 4 ile Tek Porttan TCP Dağıtımı

Katman 4 çalışmasında HAProxy, TCP bağlantısının iki yönlü veri akışını seçilen backend sunucusuna iletir. Yük dengeleme kararı bağlantı kurulurken verilir ve bağlantının kalan bölümü normalde aynı sunucu üzerinden devam eder.

HAProxy bu modelde taşınan üst katman protokolünü bütünüyle anlamak zorunda değildir. HTTPS, veritabanı bağlantısı, posta protokolü veya özel bir TCP uygulaması taşınabilir; ancak aynı backend havuzundaki sunucuların istemcinin beklediği uyumlu hizmeti sunması gerekir.

HTTPS Passthrough için Katman 4 Örneği

Örnek bir HTTPS passthrough tasarımında HAProxy, 443 numaralı portu dinler ve şifreli bağlantıları iki uygulama sunucusuna dağıtır. Yapılandırmanın temel bileşenleri şu şekilde kurulur:

1. Frontend bölümünde 443 numaralı port bind ile dinlenir.
2. Frontend ve ilgili backend için mode tcp seçilir.
3. default_backend ile HTTPS sunucu havuzu belirlenir.
4. Backend içinde aynı TLS hizmetini sunan iki veya daha fazla sunucu tanımlanır.
5. roundrobin veya iş yüküne uygun başka bir dengeleme algoritması seçilir.
6. Sunucu satırlarındaki sağlık kontrolleriyle erişilemeyen hedeflerin yeni bağlantı alması engellenir.

Bu tasarımda sertifika ve özel anahtarlar backend sunucularında kalır. HAProxy şifreli HTTP isteğini ayrıştıramadığı için HTTP Host alanına, URL yoluna veya diğer HTTP başlıklarına göre yönlendirme yapamaz. Bağlantılar yalnız sunucu havuzu içinde dağıtılacaksa bu sınırlama kabul edilebilir.

Katman 4'te Sağlık Kontrolü ve Bağlantı Hataları

Temel TCP sağlık kontrolü, HAProxy'nin hedef porta bağlantı kurup kuramadığını sınar. Portun açık olması uygulamanın doğru yanıt verdiğini kanıtlamaz; protokol destekliyorsa tcp-check ile belirli bir istek ve beklenen yanıt dizisi de denetlenebilir.

Sağlıklı backend kalmadığında yeni istemci bağlantısı tamamlanamayabilir veya HAProxy bağlantıyı kapatabilir. Katman 4 modelinde HTTP durum kodu üretileceği varsayılmamalıdır; istemcinin gördüğü hata, taşınan protokole ve bağlantının hangi aşamada kesildiğine bağlıdır.

Katman 7 ile HTTP ve HTTPS Yönlendirmesi

Katman 7 çalışmasında HAProxy, HTTP isteklerinin ve yanıtlarının yapısını analiz eder. İstek hedefi, Host bilgisi, yöntem, URL yolu, çerez veya belirli başlık alanları ACL koşullarında kullanılabilir.

Bu model, 443 numaralı tek porttan gelen isteklerin farklı uygulama havuzlarına gönderilmesini mümkün kılar. Örneğin API alan adı ayrı bir backend'e, statik dosya yolu başka bir backend'e, eşleşmeyen istekler ise varsayılan web uygulamasına aktarılabilir.

TLS Sonlandırmalı Katman 7 Örneği

Örnek tasarımda HTTPS bağlantısı HAProxy üzerinde sonlandırılır ve HTTP isteği içeriğine göre üç backend arasından seçim yapılır:

1. Frontend, 443 numaralı portu TLS etkin biçimde dinler ve uygun sertifika dosyalarını kullanır.
2. Frontend için mode http seçilir; HAProxy isteği HTTP yapısına göre işler.
3. Bir ACL, Host alanının API alan adıyla eşleşip eşleşmediğini kontrol eder.
4. İkinci bir ACL, URL yolunun statik içerik için ayrılmış önekle başlayıp başlamadığını sınar.
5. use_backend kuralları, API ve statik içerik isteklerini kendi havuzlarına gönderir.
6. default_backend, hiçbir özel kurala uymayan istekleri ana uygulamaya aktarır.

HAProxy ile backend arasındaki bağlantı düz HTTP olarak kurulabileceği gibi tekrar TLS ile şifrelenebilir. Yeniden şifreleme seçildiğinde backend sertifikasının güven zinciri ve sunucu adı eşleşmesi ayrıca doğrulanmalıdır.

HAProxy HTTP Verisini Ne Zaman Görebilir?

Şifrelenmemiş HTTP trafiğinde Host ve URL yolu doğrudan incelenebilir. HTTPS kullanıldığında bu veriler TLS oturumunun içindedir; HAProxy'nin HTTP tabanlı ACL kuralları uygulayabilmesi için TLS bağlantısını sonlandırması gerekir.

TLS sonlandırılmadan yalnız TCP akışı ve açık biçimde erişilebilen TLS el sıkışması verileri değerlendirilebilir. HTTP Host alanı ile URL yolu, şifreli uygulama verisinin parçası olduğundan passthrough sırasında okunamaz.

Katman 4 ve Katman 7 Karşılaştırması

Aşağıdaki tablo, TCP bağlantısını aktarma ile HTTP isteklerini işleme arasındaki temel farkları gösterir. Performans ve kapasite sonuçları trafik yapısına, şifreleme kullanımına, donanıma ve yapılandırmaya bağlıdır.

TLS Passthrough, TLS Sonlandırma, SNI ve Host

TLS modelinin seçimi, HAProxy'nin hangi verileri görebileceğini ve sertifika özel anahtarlarının nerede tutulacağını belirler. Passthrough ile sonlandırma aynı işlem değildir ve aynı güvenlik sorumluluklarını oluşturmaz.

TLS Passthrough

TLS passthrough sırasında HAProxy, istemci ile backend arasındaki şifreli bayt akışını TCP modunda iletir. Sertifika backend tarafından sunulur ve özel anahtar HAProxy üzerinde bulunmaz.

HAProxy, gerekli içerik inceleme süresi ve kurallar tanımlandığında TLS ClientHello içindeki görünür SNI değerini okuyabilir. Bu değer üzerinden sınırlı alan adı yönlendirmesi yapılabilir; ancak SNI'nin gönderileceği veya her bağlantıda görünür olacağı garanti edilemez.

TLS Sonlandırma

TLS sonlandırmada HAProxy, sunacağı sertifikayı ve ona karşılık gelen özel anahtarı kullanır. İstemciyle kurulan TLS oturumu HAProxy'de çözülür ve elde edilen HTTP isteği mode http kurallarıyla işlenir.

Bu model Host, yol, çerez ve HTTP başlıklarına göre yönlendirme yapılmasına izin verir. Buna karşılık sertifika yenileme, özel anahtar koruması, TLS politikası ve HAProxy ile backend arasındaki trafiğin korunması yük dengeleyici mimarisinin parçası olur.

SNI ve HTTP Host Ayrımı

SNI, TLS el sıkışması sırasında sertifika veya hedef seçimine yardımcı olan sunucu adı bilgisidir. HTTP Host ise TLS kurulduktan sonra gönderilen HTTP isteğinin hedef sunucusunu ve gerekirse portunu belirtir.

İki değer çoğu normal web isteğinde ilişkili olsa da aynı protokol alanı değildir ve farklı zamanlarda işlenir. SNI eşleşmesi, HTTP Host değerinin aynı olduğunu veya isteğin belirli bir URL yoluna gittiğini kanıtlamaz.

Sağlık Kontrolleri, Dengeleme ve Oturum Sürekliliği

Tek porttan trafik dağıtmak yalnız backend seçmekten ibaret değildir. Sunucuların trafik kabul etmeye hazır olup olmadığı, dağıtım algoritması ve aynı istemcinin sonraki isteklerinin nasıl ele alınacağı birlikte tasarlanmalıdır.

Sağlık Kontrolleri

Sağlık kontrolünün türü, frontend veya backend için seçilen TCP/HTTP modundan bağımsızdır. Temel kontrol yalnız TCP bağlantısını sınarken tcp-check belirli bir istek ve yanıt akışını denetleyebilir. HTTP hizmeti sunan bir hedefte, TCP modunda trafik aktarılırken de option httpchk kullanılabilir; kontrolün portu ve gerekiyorsa TLS ayarı ayrıca tanımlanır.

option httpchk ve HTTP kontrol kurallarıyla belirli bir yol istenebilir. Ek bir yanıt koşulu tanımlanmadığında 2xx ve 3xx yanıtları sağlıklı kabul edilir; uygulamanın hazır olduğunu yalnız 200 yanıtı gösteriyorsa beklenen durum kodu buna göre sınırlandırılmalıdır.

Kontrol yolu, uygulamanın gerçekten trafik kabul etmeye hazır olup olmadığını yansıtmalıdır. Yalnız uygulamanın ana süreci çalışıyor diye her zaman başarılı dönen bir uç nokta, veritabanı veya zorunlu bağımlılık arızasını gizleyebilir. Çok ağır bir kontrol ise uygulama üzerinde gereksiz yük oluşturabilir.

Dengeleme Algoritması

roundrobin, uygun sunucular arasında sırayla seçim yapar ve benzer kapasitedeki sunucular için anlaşılır bir başlangıç noktasıdır. leastconn, etkin bağlantısı daha az olan sunucuya öncelik verir ve uzun süre açık kalan bağlantıların bulunduğu bazı iş yüklerinde daha dengeli sonuç verebilir.

Algoritma seçimi tek başına eşit kaynak tüketimi garanti etmez. İsteklerin işlem süresi, bağlantı ömrü, sunucu ağırlıkları ve uygulamanın kendi önbellek davranışı ölçülmelidir.

Oturum Sürekliliği

TCP modunda kaynak IP adresine dayalı stick-table kullanımı belirli istemcileri aynı sunucuya yönlendirebilir. NAT veya CGNAT arkasındaki çok sayıda kullanıcı aynı kaynak adresi paylaşabileceği için bu yöntem gerçek kullanıcı kimliği olarak görülmemelidir.

HTTP modunda HAProxy çerezi veya uygulamadan alınan başka bir değer kullanılabilir. Oturum sürekliliği yalnız uygulama gerçekten sunucuya bağlı durum tutuyorsa eklenmelidir; gereksiz kalıcılık sağlıklı sunucular arasındaki dağılımı bozabilir.

Günlükler ve İstemci IP Adresi

TCP günlükleri bağlantı süresi, backend seçimi, sunucu bağlantısı ve aktarım sonucu gibi bilgileri öne çıkarır. HTTP günlükleri bunlara ek olarak yöntem, istek, durum kodu ve HTTP aşamalarına ilişkin zamanlamaları gösterebilir.

Backend çoğu proxy kurulumunda bağlantının kaynağı olarak HAProxy adresini görür. Gerçek istemci IP adresinin PROXY protokolüyle aktarılması planlanıyorsa HAProxy ve backend hizmeti bunu birlikte desteklemelidir. Test istemcisinin bu bağlantıda kullandığı kaynak IP adresini proxy ve uygulama günlüklerinde görünen adreslerle karşılaştırın. Günlüklerde tutulacak alanları, veri saklama süresini ve erişim yetkilerini önceden belirleyin.

Hata Davranışı, Kapasite ve Yüksek Erişilebilirlik

Bir backend sunucusunun devre dışı kalması ile HAProxy düğümünün devre dışı kalması farklı arızalardır. Sağlık kontrolleri backend arızasını yönetebilir; tek HAProxy örneğinin kaybında hizmetin durmasını önlemek için ayrıca yüksek erişilebilirlik tasarımı gerekir.

Kapasiteyi Gerçek Trafikle Ölçme

Kapasite planı yalnız saniyedeki bağlantı veya istek sayısına dayandırılmamalıdır. Eş zamanlı bağlantılar, bağlantı ömrü, TLS el sıkışmaları, HTTP sürümü, yanıt boyutu, günlük yazma hızı ve sağlık kontrolleri kaynak tüketimini değiştirebilir.

Katman 4'ün her koşulda daha düşük gecikme sunacağı veya Katman 7'nin kapasiteyi belirli oranda düşüreceği söylenemez. Test yükü, üretimdeki bağlantı ve istek dağılımını temsil etmeli; işlemci, bellek, bağlantı kuyruğu, hata oranı ve uçtan uca gecikme birlikte izlenmelidir.

Tek Hata Noktasını Kaldırma

Tek HAProxy düğümü, arkasında çok sayıda sağlıklı sunucu bulunsa bile hizmet için tek hata noktası oluşturur. İkinci bir HAProxy düğümü, sanal IP adresi devri veya uygun bir üst yük dengeleme mekanizmasıyla birlikte planlanabilir.

Yedek düğümün yalnız çalışıyor olması yeterli değildir. Yapılandırmanın, sertifikaların, çalışma sırasında oluşan verilerin ve gerekli oturum tablolarının nasıl eşitleneceği belirlenmelidir.

HAProxy Yapılandırmasını Test Etme ve Geri Dönüş

Yeni yapılandırmayı önce sözdizimi bakımından doğrulayın, ardından kontrollü bir test ortamında çalıştırın. Yanlış Host, bilinmeyen SNI, eşleşmeyen URL yolu, tüm backend'lerin kapalı olması, uzun süreli TCP bağlantısı ve sertifika hatası gibi durumları da test edin.

Değişikliği kontrollü yeniden yüklemeyle uygulayın ve önceki yapılandırmayı geri dönüş için saklayın. Yeniden yüklemeden sonra işlemin çalıştığını, beklenen backend seçiminin yapıldığını ve sağlık durumunun korunduğunu doğrulayın.