Bugün sizlere şirketimiz için yeni bir iç ağ oluşturma fikrinin nasıl ortaya çıktığını ve uygulandığını anlatacağım. Yönetimin pozisyonu, müşteri için olduğu gibi aynı tam teşekküllü projeyi kendiniz için de yapmanız gerektiğidir. Bunu kendimiz için iyi yaparsak müşteriyi davet edebilir ve ona sunduklarımızın ne kadar işe yaradığını gösterebiliriz. Bu nedenle, Moskova ofisi için yeni bir ağ konseptinin geliştirilmesine tüm üretim döngüsünü kullanarak çok ayrıntılı bir şekilde yaklaştık: departman ihtiyaçlarının analizi → teknik bir çözümün seçimi → tasarım → uygulama → test. Öyleyse başlayalım.
Teknik Bir Çözüm Seçmek: Mutant Sığınağı
Karmaşık bir otomatik sistem üzerinde çalışma prosedürü şu anda en iyi şekilde GOST 34.601-90 “Otomatik sistemlerde açıklanmaktadır. Yaratılışın Aşamaları” dedik ve ona göre çalıştık. Zaten gereksinimlerin oluşumu ve konsept geliştirme aşamalarında ilk zorluklarla karşılaştık. Çeşitli profillerdeki kuruluşlar (bankalar, sigorta şirketleri, yazılım geliştiriciler vb.) görevleri ve standartları için, özellikleri açık ve standartlaştırılmış belirli ağ türlerine ihtiyaç duyarlar. Ancak bu bizde işe yaramayacaktır.
Neden?
Jet Infosystems çok çeşitliliğe sahip büyük bir BT şirketidir. Aynı zamanda dahili destek departmanımız küçüktür (ama gururludur), temel hizmetlerin ve sistemlerin işlevselliğini sağlar. Şirket, farklı işlevleri yerine getiren birçok bölüm içerir: bunlar birkaç güçlü dış kaynak ekibi ve şirket içi iş sistemleri ve bilgi güvenliği geliştiricileri ve bilgi işlem sistemlerinin mimarlarıdır - genel olarak kim olursa olsun. Buna bağlı olarak görevleri, sistemleri ve güvenlik politikaları da farklıdır. Bu da beklendiği gibi ihtiyaç analizi ve standardizasyon sürecinde zorluklar yarattı.
Örneğin burada geliştirme departmanı var: Çalışanları çok sayıda müşteri için kod yazıyor ve test ediyor. Çoğu zaman test ortamlarının hızlı bir şekilde organize edilmesi gerekiyor ve açıkçası her proje için gereksinimleri formüle etmek, kaynak talep etmek ve tüm iç düzenlemelere uygun ayrı bir test ortamı oluşturmak her zaman mümkün olmuyor. Bu durum ilginç durumlara yol açıyor: Bir gün mütevazi hizmetkarınız geliştiricilerin odasına baktı ve masanın altında, açıklanamaz bir şekilde ortak bir ağa bağlı olan, 20 masaüstü bilgisayardan oluşan, düzgün çalışan bir Hadoop kümesi buldu. Şirketin BT departmanının varlığından haberi olmadığını açıklamaya değer olduğunu düşünmüyorum. Bu durum, diğerleri gibi, projenin geliştirilmesi sırasında uzun süredir acı çeken ofis altyapısının durumunu tanımlayan "mutant rezerv" teriminin doğmasından sorumluydu.
Ya da işte başka bir örnek. Periyodik olarak departman bünyesinde bir test tezgahı kurulur. Yazılım Geliştirme Merkezi'nin bazı projelerde sınırlı ölçüde kullandığı Jira ve Confluence'da da durum aynıydı. Bir süre sonra diğer departmanlar bu faydalı kaynakları öğrenip değerlendirdi ve 2018'in sonunda Jira ve Confluence "yerel programcıların oyuncağı" statüsünden "şirket kaynakları" statüsüne geçti. Artık bu sistemlere bir sahip atanmalı, SLA'lar, erişim/bilgi güvenliği politikaları, yedekleme politikaları, izleme, sorunları düzeltmek için istekleri yönlendirme kuralları tanımlanmalı - genel olarak tam teşekküllü bir bilgi sisteminin tüm nitelikleri mevcut olmalıdır .
Bölümlerimizin her biri aynı zamanda kendi ürünlerini yetiştiren bir kuluçka merkezidir. Bunlardan bazıları geliştirme aşamasında ölür, bazılarını projeler üzerinde çalışırken kullanırız, bazıları ise kök salıp kendimiz kullanmaya başladığımız ve müşterilerimize sattığımız kopya çözümler haline gelir. Bu tür her sistem için, diğer sistemlere müdahale etmeden gelişeceği ve bir noktada şirketin altyapısına entegre edilebilecek kendi ağ ortamının olması arzu edilir.
Gelişimin yanı sıra çok büyük bir 500'den fazla çalışanıyla her müşteri için ekipler oluşturuldu. Ağların ve diğer sistemlerin bakımı, uzaktan izleme, taleplerin çözümlenmesi vb. ile ilgilenirler. Yani SC'nin altyapısı aslında şu anda çalıştığı müşterinin altyapısıdır. Ağın bu bölümüyle çalışmanın özelliği, şirketimiz için iş istasyonlarının kısmen harici, kısmen dahili olmasıdır. Bu nedenle, SC için aşağıdaki yaklaşımı uyguladık - şirket, bu departmanların iş istasyonlarını harici bağlantılar olarak değerlendirerek (şubeler ve uzak kullanıcılarla benzeştirerek) ilgili departmana ağ ve diğer kaynakları sağlar.
Otoyol tasarımı: biz işletmeciyiz (sürpriz)
Tüm tuzakları değerlendirdikten sonra telekomünikasyon operatörünün ağını tek ofis çatısında topladığımızı fark ettik ve ona göre hareket etmeye başladık.
Herhangi bir dahili ve gelecekte harici tüketiciye gerekli hizmetin sağlanacağı bir çekirdek ağ oluşturduk: L2 VPN, L3 VPN veya normal L3 yönlendirme. Bazı departmanlar güvenli İnternet erişimine ihtiyaç duyarken, diğerleri güvenlik duvarları olmadan temiz erişime ihtiyaç duyarken aynı zamanda kurumsal kaynaklarımızı ve çekirdek ağımızı bunların trafiğinden korumaya ihtiyaç duyar.
Her bölümle gayri resmi olarak bir "SLA" imzaladık. Buna göre, ortaya çıkan tüm olayların önceden kararlaştırılan belirli bir süre içerisinde ortadan kaldırılması gerekmektedir. Şirketin ağ gereksinimlerinin katı olduğu ortaya çıktı. Telefon ve e-posta arızası durumunda olaya maksimum müdahale süresi 5 dakikaydı. Tipik arızalar sırasında ağ işlevselliğini geri yükleme süresi bir dakikadan fazla değildir.
Taşıyıcı düzeyinde bir ağımız olduğundan, ona yalnızca kurallara tam olarak uygun şekilde bağlanabilirsiniz. Hizmet birimleri politikaları belirler ve hizmetler sunar. Belirli sunucuların, sanal makinelerin ve iş istasyonlarının bağlantıları hakkında bilgiye bile ihtiyaçları yoktur. Ancak aynı zamanda koruma mekanizmalarına da ihtiyaç vardır çünkü tek bir bağlantının ağı devre dışı bırakmaması gerekir. Yanlışlıkla bir döngü oluşturulursa, diğer kullanıcılar bunu fark etmemelidir, yani ağdan yeterli yanıt alınması gerekir. Herhangi bir telekom operatörü, çekirdek ağı içindeki benzer görünüşte karmaşık sorunları sürekli olarak çözer. Farklı ihtiyaçlara ve trafiğe sahip birçok müşteriye hizmet vermektedir. Aynı zamanda farklı abonelerin başkalarının trafiğinden rahatsızlık yaşamaması gerekir.
Evde bu sorunu şu şekilde çözdük: IS-IS protokolünü kullanarak tam yedekli bir omurga L3 ağı kurduk. Çekirdeğin üzerine teknolojiye dayalı bir katman ağı oluşturuldu /, bir yönlendirme protokolü kullanarak . Yönlendirme protokollerinin yakınsamasını hızlandırmak için BFD teknolojisi kullanıldı.
Ağ yapısı
Testlerde bu şema mükemmel olduğunu gösterdi - herhangi bir kanal veya anahtar bağlantısı kesildiğinde, yakınsama süresi 0.1-0.2 saniyeden fazla değil, minimum paket kaybı (genellikle yok), TCP oturumları bozulmadı, telefon konuşmaları kesintiye uğramazlar.
Alt Katman - Yönlendirme
Kaplama Katmanı - Yönlendirme
Dağıtım anahtarları olarak VXLAN lisansına sahip Huawei CE6870 anahtarları kullanıldı. Bu cihaz, kullanılan alıcı-vericilere bağlı olarak aboneleri 10 Gbit/s hızında bağlamanıza ve omurgaya 40-100 Gbit/s hızında bağlanmanıza olanak tanıyan optimum fiyat/kalite oranına sahiptir.
Huawei CE6870 anahtarları
Çekirdek anahtar olarak Huawei CE8850 anahtarlar kullanıldı. Amaç trafiği hızlı ve güvenilir bir şekilde iletmektir. Dağıtım anahtarları dışında hiçbir cihaz onlara bağlı değil, VXLAN hakkında hiçbir şey bilmiyorlar, bu nedenle L32 yönlendirme ve IS-IS ve MP-BGP desteği sağlayan temel lisansa sahip 40 100/3 Gbps bağlantı noktasına sahip bir model seçildi. protokoller.
Alttaki Huawei CE8850 çekirdek anahtarıdır
Tasarım aşamasında, ekip içinde çekirdek ağ düğümlerine hataya dayanıklı bir bağlantı uygulamak için kullanılabilecek teknolojiler hakkında bir tartışma çıktı. Moskova ofisimiz üç binada bulunmaktadır, her birinde iki adet Huawei CE7 dağıtım anahtarının kurulu olduğu 6870 dağıtım odamız bulunmaktadır (birkaç dağıtım odasına yalnızca erişim anahtarları monte edilmiştir). Ağ konseptini geliştirirken iki yedeklilik seçeneği dikkate alındı:
- Dağıtım anahtarlarının her çapraz bağlantı odasında hataya dayanıklı bir yığın halinde birleştirilmesi. Artıları: basitlik ve kurulum kolaylığı. Dezavantajları: Ağ cihazlarının donanım yazılımında hatalar oluştuğunda (“bellek sızıntıları” ve benzeri) tüm yığının arızalanma olasılığı daha yüksektir.
- Cihazları dağıtım anahtarlarına bağlamak için M-LAG ve Anycast ağ geçidi teknolojilerini uygulayın.
Sonunda ikinci seçeneğe karar verdik. Yapılandırması biraz daha zordur, ancak pratikte performansını ve yüksek güvenilirliğini göstermiştir.
Öncelikle uç cihazları dağıtım anahtarlarına bağlamayı düşünelim:
Geçmek
İki dağıtım anahtarına bir erişim anahtarı, sunucu veya hataya dayanıklı bağlantı gerektiren başka bir cihaz dahildir. M-LAG teknolojisi veri bağlantısı düzeyinde artıklık sağlar. İki dağıtım anahtarının bağlı ekipmana tek bir cihaz gibi göründüğü varsayılmaktadır. Artıklık ve yük dengeleme, LACP protokolü kullanılarak gerçekleştirilir.
Anycast ağ geçidi teknolojisi, ağ düzeyinde yedeklilik sağlar. Dağıtım anahtarlarının her birinde oldukça fazla sayıda VRF yapılandırılmıştır (her VRF kendi amaçlarına yöneliktir - ayrı ayrı "normal" kullanıcılar için, ayrı telefon için, ayrı olarak çeşitli test ve geliştirme ortamları için vb.) ve her birinde VRF'de yapılandırılmış birden fazla VLAN vardır. Ağımızda dağıtım anahtarları, onlara bağlı tüm cihazlar için varsayılan ağ geçitleridir. VLAN arayüzlerine karşılık gelen IP adresleri her iki dağıtım anahtarı için de aynıdır. Trafik en yakın anahtar üzerinden yönlendirilir.
Şimdi dağıtım anahtarlarını çekirdeğe bağlamaya bakalım:
IS-IS protokolü kullanılarak ağ düzeyinde hata toleransı sağlanır. Anahtarlar arasında 3G hızında ayrı bir L100 iletişim hattının sağlandığını lütfen unutmayın. Fiziksel olarak bu iletişim hattı bir Doğrudan Erişim kablosudur; sağda Huawei CE6870 anahtarlarının fotoğrafında görülebilir.
Bir alternatif "dürüst" tamamen bağlantılı çift yıldız topolojisi düzenlemek olabilir, ancak yukarıda belirtildiği gibi üç binada 7 adet çapraz bağlantılı odamız var. Buna göre, eğer “çift yıldızlı” bir topoloji seçmiş olsaydık, tam olarak iki kat daha fazla “uzun menzilli” 40G alıcı-vericiye ihtiyacımız olacaktı. Buradaki tasarruflar çok önemli.
VXLAN ve Anycast ağ geçidi teknolojilerinin birlikte nasıl çalıştığı hakkında birkaç söz söylemek gerekiyor. VXLAN, ayrıntılara girmeden, UDP paketleri içindeki Ethernet çerçevelerini taşımak için kullanılan bir tüneldir. Dağıtım anahtarlarının geri döngü arayüzleri, VXLAN tünelinin hedef IP adresi olarak kullanılır. Her çapraz bağlantıda aynı geridöngü arayüz adreslerine sahip iki anahtar bulunur, böylece bunlardan herhangi birine bir paket gelebilir ve buradan bir Ethernet çerçevesi çıkarılabilir.
Anahtar, alınan çerçevenin hedef MAC adresini biliyorsa çerçeve hedefine doğru bir şekilde iletilecektir. Aynı çapraz bağlantıya kurulan her iki dağıtım anahtarının da erişim anahtarlarından "gelen" tüm MAC adresleri hakkında güncel bilgilere sahip olmasını sağlamak için, M-LAG mekanizması MAC adres tablolarının (ARP'nin yanı sıra) senkronize edilmesinden sorumludur. tabloları) her iki anahtar M-LAG çiftinde.
Trafik dengeleme, dağıtım anahtarlarının geri döngü arayüzlerine giden çeşitli yolların alt katman ağındaki varlığı nedeniyle elde edilir.
Bunun yerine bir sonuca
Yukarıda bahsedildiği gibi, test ve çalışma sırasında ağ yüksek güvenilirlik (tipik arızalar için kurtarma süresi yüzlerce milisaniyeden fazla değildir) ve iyi performans gösterdi - her çapraz bağlantı çekirdeğe iki adet 40 Gbit/s kanalla bağlanır. Ağımızdaki erişim anahtarları yığılmış ve iki adet 10 Gbit/s kanallı LACP/M-LAG aracılığıyla dağıtım anahtarlarına bağlanmıştır. Bir yığın genellikle her biri 5 bağlantı noktasına sahip 48 anahtar içerir ve her çapraz bağlantıda dağıtıma en fazla 10 erişim yığını bağlanır. Böylece omurga, maksimum teorik yükte bile kullanıcı başına yaklaşık 30 Mbit/s hız sağlar; bu yazının yazıldığı sırada tüm pratik uygulamalarımız için yeterliydi.
Ağ, hem L2 hem de L3 yoluyla herhangi bir keyfi bağlı cihazın eşleşmesini sorunsuz bir şekilde organize etmenize olanak tanır ve trafiğin (bilgi güvenliği hizmetinin beğendiği) ve hata alanlarının (operasyon ekibinin beğendiği) tam izolasyonunu sağlar.
Bir sonraki bölümde sizlere yeni ağa nasıl geçtiğimizi anlatacağız. Bizi izlemeye devam edin!
Maxim Klochkov
Ağ denetimi ve karmaşık projeler grubunun kıdemli danışmanı
Ağ Çözümleri Merkezi
"Jet Bilgi Sistemleri"
Kaynak: habr.com