Katman 3 LACP hedef adresinin tam olarak nasıl ve tam olarak işlenmesi nedir?


54

Bir yıl önceki daha önceki bir soruyu temel alan ( Multiplexed 1 Gbps Ethernet? ), Her yerdeki LACP bağlantılarına sahip yeni bir ISS'ye gidip yeni bir raf kurdum. Buna ihtiyacımız var, çünkü Internet üzerinden 1Gbps kümülatif olarak binlerce istemci bilgisayara hizmet veren ayrı sunucularımız (bir uygulama, bir IP) var.

Bu LACP fikrinin, 10GoE anahtarlara ve NIC'lere bir servet harcamadan 1Gbps bariyerini kırmamıza izin vermesi gerekiyor. Ne yazık ki, giden trafik dağılımıyla ilgili bazı sorunlarla karşılaştım. (Bu, Kevin Kuphal'ın yukarıdaki bağlantılı sorudaki uyarısına rağmen.)

ISS'nin yönlendiricisi bir tür Cisco'dur. (Bunu MAC adresinden çıkardım.) Anahtarım bir HP ProCurve 2510G-24. Ve sunucular Debian Lenny'yi çalıştıran HP DL 380 G5'ler. Bir sunucu sıcak bekleme durumunda. Uygulamamız kümelenemez. IP, MAC ve arabirimlerle tüm ilgili ağ düğümlerini içeren basitleştirilmiş bir ağ şeması.

alt metin

Tüm ayrıntılara sahip olsa da, sorunumu çözmek ve çalışmak biraz zor. Yani, sadelik uğruna, burada düğümlere ve fiziksel bağlantılara indirgenmiş bir ağ şeması.

alt metin

Ben de çıktım ve kitimi yeni rafa taktım ve ISS kablolarımı yönlendiricilerinden bağladım. Her iki sunucunun da anahtarım için bir LACP bağlantısı var ve anahtarın ISP yönlendiricisine bir LACP bağlantısı var. En başından beri, LACP yapılandırmamın doğru olmadığını fark ettim: testler, her sunucuya giden ve giden tüm trafiğin, yalnızca hem sunucu-to-to-switch-to-to-router arasında tek bir fiziksel GoE bağlantısının üzerinden geçtiğini gösterdi.

alt metin

Linux NIC bağlantısıyla ilgili bazı Google aramaları ve çok sayıda RTMF süresi ile, NIC bağlantısını değiştirerek kontrol edebileceğimi öğrendim. /etc/modules

# /etc/modules: kernel modules to load at boot time.
# mode=4 is for lacp
# xmit_hash_policy=1 means to use layer3+4(TCP/IP src/dst) & not default layer2 
bonding mode=4 miimon=100 max_bonds=2 xmit_hash_policy=1

loop

Bu, sunucumu beklendiği gibi her iki NIC üzerinden de terk etti. Ancak trafik hala anahtardan yönlendiriciye yalnızca bir fiziksel bağlantı üzerinden geçiyordu .

alt metin

Her iki fiziksel bağlantının üzerinden geçen bu trafiğe ihtiyacımız var. 2510G-24'ün Yönetim ve Konfigürasyon Kılavuzunu okuduktan ve yeniden okuduktan sonra şunu buldum:

[LACP], dışarıdan gelen trafiği kanal bağlantıları üzerine dağıtmak için kaynak hedef adres çiftlerini (SA / DA) kullanır. SA / DA (kaynak adres / hedef adres), anahtarın giden trafiği, kaynak / hedef adres çiftleri temelinde ana gruptaki bağlantılara dağıtmasına neden olur. Diğer bir deyişle, anahtar aynı kaynak adresinden gelen trafiği aynı trunk bağlantısıyla aynı hedef adrese gönderir ve aynı kaynak adresinden gelen trafiği, aralarındaki yol atamalarının rotasyonuna bağlı olarak farklı bir bağlantı üzerinden farklı bir hedef adrese gönderir. Bagajdaki bağlantılar.

Görünen o ki, bağlı bir bağlantı yalnızca bir MAC adresi sunuyor ve bu nedenle sunucu-yönlendirici yolum anahtar-yönlendiriciden her zaman bir yolun üzerinde olacak çünkü anahtar bir MAC görüyor (ikisi iki değil - bir Her bir bağlantı noktası) her iki LACP'd bağlantısı için.

Anladım. Ama istediğim bu:

alt metin

Daha pahalı bir HP ProCurve anahtarı, 2910al'ın değerinde seviye 3 kaynak ve hedef adreslerini kullanmasıdır. ProCurve 2910al Yönetim ve Konfigürasyon Kılavuzu'nun "Kesilmiş Bağlantılar Üzerindeki Giden Trafik Dağılımı" bölümünden :

Trafiğin bir ana hat üzerinden fiili dağılımı, Kaynak Adresinden ve Hedef Adresinden bitlerin kullanıldığı bir hesaplamaya bağlıdır. Bir IP adresi mevcut olduğunda, hesaplama IP kaynak adresinin ve IP varış adresinin son beş bitini içerir, aksi takdirde MAC adresleri kullanılır.

TAMAM. Bu nedenle, istediğim gibi çalışması için, kaynak adresim sabit olduğundan hedef adres anahtarıdır. Bu benim soruma yol açar:

Katman 3 LACP karma işlemi tam olarak ve özellikle nasıl çalışır?

Hangi hedef adresin kullanıldığını bilmem gerekiyor:

  • müşterinin IP adresi , son hedef?
  • Veya yönlendiricinin IP'si , bir sonraki fiziksel bağlantı iletim hedefi.

Gitmedik ve henüz bir değiştirme anahtarı almadık. Lütfen, 3. katmandaki LACP hedef adresinin karma değerinin ihtiyacım olup olmadığını tam olarak anlamama yardım edin. Başka bir işe yaramaz anahtar satın almak bir seçenek değildir.


13
Mükemmel, iyi araştırılmış bir soru! Ne yazık ki, cevabını bilmiyorum ...
Doug Luxem

ProCurve'deki her bir köprünün / bagajın yayılma ağacı maliyetine bakabilir misiniz?
dbasnett

Ayrıca devlet ve öncelik? Görünüşe göre, HP <---> Cisco, sandıkların aynı önceliğe sahip olamayacağı ve sonunda bloke olabileceği anlaşılıyor. Satıcıları karıştırmamak için bir reklam ????
dbasnett

6
Bu muhtemelen Server
Fault'de

Umarım birileri, soruya verilen cevapla aynı miktarda ilgilenebilir.
Neil Trodden

Yanıtlar:


14

Aradığın şeye genellikle "iletim karma politikası" veya "iletim karma algoritması" denir. Bir çerçevenin seçileceği, bir çerçevenin iletileceği bir grup toplu porttan kontrol edilir.

Ellerimi 802.3ad standardına sokmak zor oldu çünkü para harcamak istemiyorum. Bunu söyledikten sonra, aradığınızı biraz aydınlatan yarı-resmi bir kaynaktan bazı bilgileri topladım. 802.3ad standardını karşılayan 2007 Ottawa, ON, CA IEEE Yüksek Hızlı Çalışma Grubu'nun bu sunumu uyarınca , "çerçeve dağıtıcısı" için belirli algoritmalar zorunlu değildir:

Bu standart, belirli bir dağıtım algoritmasını zorunlu kılmaz; Bununla birlikte, herhangi bir dağıtım algoritması, çerçeveler 43.2.3'te belirtilen bir Çerçeve Toplayıcı tarafından alındığında, algoritmanın aşağıdakilere yol açmamasını sağlamalıdır: a) Herhangi bir konuşmanın parçası olan çerçevelerin yanlış sıralanması veya b) Çerçevelerin çoğaltılması . Çerçeve sıralamasını sürdürmek için yukarıdaki gereksinim, belirli bir sohbeti oluşturan tüm karelerin MAC İstemcisi tarafından oluşturulan sırayla tek bir bağlantıda iletilmesini sağlamak; Bu nedenle, bu gereksinim, herhangi bir bilginin MAC çerçevesine eklenmesini (ya da değiştirilmesini) ya da çerçeveleri yeniden sipariş etmek için karşılık gelen Çerçeve Toplayıcısının parçası üzerinde herhangi bir tamponlama veya işlemeyi içermez.

Bu nedenle, bir anahtar / NIC sürücüsünün iletilen çerçeveleri dağıtmak için kullandığı algoritma ne olursa olsun, bu sunumda belirtilen şartlara uymalıdır (muhtemelen standarttan alıntı yapıyordu). Belirlenmiş belirli bir algoritma yoktur, yalnızca tanımlanmış bir uyumlu davranış vardır.

Belirlenmiş bir algoritma olmasa da, böyle bir algoritmanın nasıl işe yaradığına dair bir fikir edinmek için belirli bir uygulamaya bakabiliriz. Örneğin, Linux çekirdeği "bonding" sürücüsü, işlevi uygulayan 802.3ad uyumlu bir iletim karma politikasına sahiptir (bkz. Çekirdek kaynağının Documentation \ networking dizinindeki bonding.txt):

Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) 
    XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>

Bu, hem kaynak hem de hedef IP adreslerinin yanı sıra kaynak ve hedef MAC adreslerinin de port seçimini etkilemesine neden olur.

Bu karma kullanımda kullanılan hedef IP adresi, çerçevede bulunan adres olacaktır. Bunu düşünmek için bir saniye ayırın. Yönlendiricinin IP adresi, sunucunuzdan İnternet'e bir Ethernet çerçeve başlığında, böyle bir çerçevenin hiçbir yerinde kapsüllenmez. Yönlendiricinin MAC adresi böyle bir çerçevenin başlığında bulunur, ancak yönlendiricinin IP adresi değildir. Çerçevenin yükünde kapsanan hedef IP adresi, sunucunuza talepte bulunan İnternet istemcisinin adresi olacaktır.

Hem kaynak hem de hedef IP adreslerini dikkate alan ve çok çeşitli müşteri havuzuna sahip olduğunuzu varsayan bir karma politika, sizin için oldukça iyi sonuç vermelidir. Genel olarak, bu tür bir toplu altyapı boyunca akan trafikteki daha geniş çapta değişen kaynak ve / veya hedef IP adresleri, bir katman 3 tabanlı iletim karma politikası kullanıldığında daha verimli bir toplanma ile sonuçlanacaktır.

Diyagramlarınız, doğrudan İnternet'ten sunuculara gelen istekleri gösterir, ancak bir proxy'nin duruma ne yapabileceğini belirtmek gerekir. İstemcilerden sunucularınıza proxy istemiyorsanız, Chris'in cevabında konuştuğu gibi darboğazlara neden olabilirsiniz. Bu proxy, isteği İnternet kaynak kodunun IP adresi yerine kendi kaynak IP adresinden yapıyorsa, kesinlikle katman 3 tabanlı iletim sağlama ilkesinde mümkün olan daha az "akış" elde edersiniz.

Bir aktarım karma politikası ayrıca, 802.3ad standardındaki gerekliliklere uygun olduğu sürece, katman 4 bilgilerini de (TCP / UDP port numaraları) dikkate alabilir. Böyle bir algoritma, sorunuzda referans olarak gördüğünüz gibi Linux çekirdeğindedir. Bu algoritmaya ilişkin belgelerin, parçalanma nedeniyle trafiğin mutlaka aynı yol boyunca akmayacağı ve dolayısıyla algoritmanın kesinlikle 802.3ad uyumlu olmadığı konusunda uyardığı konusunda dikkatli olun.


Evet, linux sunucusunun "iletim karma politikası" nı sıraladım . (Bu soruyu mümkün kılan çok eğitici bir deneyim.) Beni zor durumda bırakan lanet anahtar. IP çerçeveleri hakkındaki bilgiler için teşekkürler - Ağın alt seviyelerinin ne kadar düşük olacağı konusunda biraz zayıfım. Aklımda çerçeve yönlendiriciye, hedef yükte daha derin olacak şekilde yönlendirildi. : P
Stu Thompson,

5

Çok şaşırtıcı bir şekilde, birkaç gün önce yaptığımız testler, xmit_hash_policy = layer3 + 4'ün doğrudan bağlı iki linux sunucusu arasında herhangi bir etkisi olmayacağını, tüm trafiğin bir bağlantı noktasını kullanacağını gösterdi. her ikisi de xen'i bir bağlama aygıtı olarak bağlayan 1 köprü ile çalıştırır. en açık şekilde, köprü soruna neden olabilir, sadece ip + port tabanlı karma kullanılacağını düşünerek AT ALL'de mantıklı gelmez.

Bazı insanların gerçekte 180 MB + 'lık bağlanmış bağlantıları (örn. Kullanıcı kullanıcıları) zorlayabildiğini biliyorum, bu yüzden genel olarak işe yarıyor. Bakılması muhtemel şeyler: - Eski CentOS 5.4 kullandık - OP'ler örneği, ikinci LACP'nin bağlantıları "mutsuzlaştırdığı" anlamına gelir - bu hiç mantıklı geliyor mu?

Bu konu ve dokümantasyon okuma vb. Bana ne gösterdi:

  • Genel olarak herkes bu konuda çok şey bilir, teoriyi bağlanma yönteminden ve hatta IEEE standartlarından alıntı yapmakta iyidir, ancak pratik deneyim hiçbir şeye yakın değildir.
  • RHEL belgeleri en iyi şekilde eksik.
  • Yapıştırma belgeleri 2001 yılına ait ve yeterince güncel değil
  • layer2 + 3 modu görünüşte CentOS'ta değil (modinfo'da görünmüyor ve testimizde etkinleştirildiğinde tüm trafiği bıraktı)
  • SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) ve RedHat (BONDING_OPTS) 'nin her bir bağ modu ayarını belirtmek için farklı yolları olmasına yardımcı olmaz
  • CentOS / RHEL5 çekirdek modülü "SMP güvenli" dir, ancak "SMP özellikli" değildir (bkz. Facebook yüksek performans konuşması) - bir CPU üzerinde ölçeklendirme yapmaz, bu nedenle daha yüksek cpu saatine sahip> birçok çekirdek

Herhangi biri iyi bir yüksek performanslı yapıştırma ayarına sahipse , ya da ne hakkında konuştuğunu gerçekten bilirse, LACP kullanarak ONE çalışan bir örneği belgelemek için yeni bir küçük yazı yazmak için yarım saat sürselerdi, garip şeyler ve bant genişliği yok > bir bağlantı


Daha da kötüsü var: Debian'ın farklı sürümleri, bağı yapılandırmak için farklı yöntemlere sahip! Aslında, bağımı nasıl iyi bir trafik alıyor gibi göründüğü bir blog gönderisine nasıl kurduğumu belgeledim.
Stu Thompson,

2

Anahtarınız gerçek L3 hedefini görürse, bunun üzerinde karma olabilir. Temel olarak 2 bağlantınız varsa, 1 numaralı bağlantının tek numaralı hedefler için olduğunu, 2 numaralı bağlantıların da numaralı hedefler için olduğunu düşünün. Bunu yapmak için yapılandırılmadıkça bir sonraki atlama IP'lerini kullandıklarını sanmıyorum, ancak hedefin MAC adresini kullanmakla hemen hemen aynı.

Karşılaştığınız sorun, trafiğinize bağlı olarak, hedefin her zaman tek bir sunucunun tek IP adresi olacağıdır, bu nedenle bu bağlantıyı asla kullanmazsınız. Hedef, İnternet'teki uzak sistemse, dağıtımı bile alırsınız, ancak sisteminiz hedef adres olduğu bir web sunucusuysa, anahtar her zaman kullanılabilir bağlantılardan yalnızca birinden trafik gönderir.

Orada bir yerde bir yük dengeleyicisi varsa daha da kötü bir durumda olacaksınız, çünkü "uzak" IP her zaman yük dengeleyicisinin IP'si veya sunucusu olacaktır. Yük dengeleyici ve sunucu üzerinde çok sayıda IP adresi kullanarak bunun üstesinden gelebilirsiniz, ancak bu bir kesmek.

Satıcı ufkunuzu biraz genişletmek isteyebilirsiniz. Aşırı ağlar gibi diğer satıcılar da aşağıdaki gibi şeylere sahip olabilir:

L3_L4 algoritması - Katman 3 ve Katman 4, birleşik kaynak ve hedef IP adresleri ve kaynak ve hedef TCP ve UDP bağlantı noktası numaraları. SummitStack ve Summit X250e, X450a, X450e ve X650 serisi anahtarlarda bulunur.

Bu nedenle, temel olarak müşterinin kaynak bağlantı noktası (genellikle çok fazla değişiklik gösterir) değiştiği sürece, trafiği eşit olarak dağıtabilirsiniz. Diğer üreticilerin de benzer özelliklere sahip olduğundan eminim.

Kaynak ve hedef IP'ye sahip olmak bile, karışımda bir yük dengeleyiciniz olmadıkça sıcak noktaları önlemek için yeterli olacaktır.


Teşekkürler. Yük dengeleme yok. Ve gelen trafikten endişe duymuyorum -> 50: 1 çıkış: trafik oranında. (Bu bir Web video uygulamasıdır.)
Stu Thompson

Sanırım sizin durumunuzdaki hedef size bir şey getirmeyecek çünkü anahtar hedefinizi sunucunuz olarak görecektir. L2 trafik mühendisliği çok iyi değil. Ve bu tür bir uygulamada 'hash' oldukça ilkel olacak - yapabileceğiniz en iyi şey, hangi adres (ler) kullanılıyorsa, tüm bitleri toplamak ve sonuç 0 ise bir link veya 1 çıkmasıdır. diğerinden dışarı çık.
chris

Anladığım kadarıyla yukarıdaki ProCurve 2910al alıntımdan, karma kaynak ve hedefin son beş bitinde . Öyleyse, birinin (sunucum) sabitlenmesi ne olursa olsun, diğeri Seviye 3'teki hemen hemen her müşteriye göre değişecek. Bu benim şu anki sorunum - buna karşı elde edilecek tek bir kaynak ve bir hedef adres var.
Stu Thompson

0

Bunun yönlendiriciden değil istemci IP'sinden çıktığını tahmin edeceğim. Gerçek kaynak ve hedef IP'ler paketteki sabit bir ofsette olacak ve bu işlem hızlı bir şekilde yapılacak. Yönlendirici IP'sinin karma olması MAC'ye bağlı bir arama gerektirir, değil mi?


-1

Buraya yeni döndüğüm için, şu ana kadar öğrendiğim birkaç şey: Gri saçlardan kaçınmak için, layer3 + 4 politikasını destekleyen ve Linux'ta da aynı olan iyi bir anahtara ihtiyacınız var.

Çok az durumda, ALB / SLB (mode6) adı verilen standartlara uygun kaynak makinesi daha iyi çalışabilir. Operasyonel olsa da berbat.

Ben kendim mümkün olduğunca 3 + 4 kullanmaya çalışıyorum çünkü sık sık iki komşu sistem arasındaki bant genişliğini istiyorum.

Ayrıca OpenVSwitch’i de denedim ve bir zamanlar bu trafik akışının kesildiği bir örneğe sahip oldum (her bir paket kaybetti ... hiçbir fikrim yok)

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.