Yanıtlar:
İlginç soru.
Tarihsel olarak, tamamen anahtarlamalı ağların ortaya çıkmasından önce, bir ağı alt ağlara bölmenin ana düşüncesi, tek bir çarpışma alanındaki düğüm sayısını sınırlamakla ilgiliydi. Yani, çok fazla düğümünüz olsaydı, ağ performansınız zirveye ulaşır ve sonunda aşırı çarpışmalar nedeniyle ağır yük altında çöker. Dağıtılabilecek düğüm sayısı kesin olarak birçok faktöre bağlıydı, ancak genel olarak konuşursanız, çarpışma alanını mevcut toplam bant genişliğinin% 50'sinden daha fazlasına düzenli olarak yükleyemediniz ve ağın her zaman istikrarlı olmasını sağlamışsınız. Ağda 50 düğüm o günlerde çok sayıda düğüm oldu. Yoğun kullanımlı kullanıcılarda, alt ağları başlatmaya gerek duymadan önce 20 veya 30 düğümde tepe yapmış olabilirsiniz.
Tabii ki, tamamen değiştirilmiş tam çift yönlü alt ağlarla, çarpışmalar artık bir sorun değil ve tipik masaüstü tipi kullanıcıları varsayarsak, genellikle tek bir alt ağda yüzlerce düğümü herhangi bir sorun olmadan dağıtabilirsiniz. Diğer cevapların bahsettiği gibi çok fazla yayın trafiğine sahip olmak, ağda hangi protokolleri / uygulamaları çalıştırdığınıza bağlı olarak endişe verici olabilir. Ancak, bir ağın alt ağının yayın trafiğiyle ilgili endişelerinizde size yardımcı olamayacağının farkında olun. Protokollerin birçoğu yayını bir nedenle kullanır - yani, ağdaki tüm düğümlerin gerçekte istenen uygulama düzeyi özelliklerini uygulamak için bu tür bir trafiği görmesi gerekir. Eğer yayınlanmış paketin diğer alt ağa yönlendirilmesi ve tekrar yayınlanması gerekiyorsa, basitçe ağın alt ağa alınması size bir şey almaz.
Genel olarak konuşursak, bugün, alt ağların temel nedenlerinin örgütsel, idari ve güvenlik sınırlarıyla ilgili her şeyden çok daha fazla ilgisi var.
Orijinal soru, alt ağ oluşturma düşüncelerini tetikleyen ölçülebilir ölçümler ister. Belirli numaralar açısından olduğundan emin değilim. Bu, büyük ölçüde ilgili 'uygulamalara' bağlı olacak ve genel olarak uygulanacak herhangi bir tetikleyici nokta olduğunu sanmıyorum.
Alt ağları planlamada başparmak kurallarına göre:
Bununla birlikte, alt ağları eklemek, bir miktar genel yönetim ek yükü ekler ve potansiyel olarak bir alt ağdaki düğüm adreslerinin tükenmesi ve başka bir havuzda çok fazla kalmasıyla ilgili sorunlara neden olur, vb. Ağ ve böyle daha fazla dahil olmak, bu tür bir şey. Kuşkusuz, her bir alt ağ , daha sofistike mantıksal topolojiyi korumanın yüküne ağır basan bir nedene sahip olmalıdır .
Tek bir site ise, birkaç düzineden fazla sisteminiz olmadıkça zahmet etmeyin ve o zaman bile muhtemelen gereksizdir.
Bugünlerde herkes en az 100 Mbps anahtar ve daha sık 1 Gbps kullanan, ağınızı bölümlere ayırmak için performansla ilgili tek neden aşırı yayın trafiği çekiyorsanız (yani,% 2, başımın üstünde)
Bunun temel nedeni güvenlik, yani halka açık sunucular için DMZ, finans için başka bir alt ağ veya VoIP sistemleri için ayrı bir VLAN / alt ağdır.
Sahip olabileceğiniz tüm uyumluluk gereklilikleri için kapsamı sınırlamak (örneğin, PCI) ağınızın bazı bölümlerini ayırmak için oldukça iyi bir katalizördür. Ödeme kabul / işleme ve finans sistemlerinizi bölümlere ayırmak paradan tasarruf etmenizi sağlar. Ancak genel olarak küçük bir ağın alt ağda tutulması size performans konusunda pek bir şey kazandırmayacaktır.
Diğer bir neden ise Hizmet Kalitesi ile ilgili olacaktır. Ses ve veri alanlarını ayrı ayrı çalıştırıyoruz, böylece QoS'yi voip trafiğine kolayca uygulayabiliyoruz.
Biliyor musun, ben bu soruyu daha çok düşünüyorum. Farklı ağlar (performans, güvenlik, QoS, DHCP kapsamlarını sınırlandırmak, yayın trafiğini sınırlandırmak (hem güvenlik hem de performansla ilgili olabilir)) kullanarak yeni bir ağ tasarlamak için birçok neden vardır.
Ancak, sadece alt ağa yeniden tasarım yapmak için bir ölçüm yapmayı ve geçmişte ele almam gereken ağları düşünmeyi düşünürken, tek düşünebildiğim "vay, bu beni tamamen yeniden dizayn etmek için gerçekten dağılmış bir ağa bağlamalıydı" onun için subnetting ". Başka pek çok neden var - bant genişliği, takılan cihazların cpu kullanımı, vb.
Güvenlik ve kalite çoğunlukla (söz konusu ağ kesimi söz konusu düğümleri destekleyebildiği sürece). Yazıcı trafiği, ses / telefon, IT Ops ve tabii ki sunucu bölümleri, internete bakan bölümler (internete bakan servis başına bir tane, bugün sadece popüler olanıdır, sadece "bir dmz yapacak" gibi) için ayrı bir ağ vb.
Ölçeklendirmeyi umuyorsanız (bir ağ oluşturuyorsunuz, sadece 5 sunucu değil, biz de öyle yapacağız) en kısa sürede yönlendirmeye başlayın. Çok fazla ağ, kararsız ve büyümesi zor, çünkü organik olarak büyüdüler ve çok fazla katman 2'ye sahipler.
Örnekler:
Yani, kısaca: Yayılma ağacına ihtiyacınız olduğunu düşündüğünüz yere ölçeklenirken, bunun yerine yönlendirmeyi düşünün.
Şahsen, katman 3 segmentasyonunu erişim anahtarlarına mümkün olduğunca yakın tutmayı seviyorum, çünkü
İki çekirdek anahtarın / yönlendiricinin yeterli olmadığı daha büyük / daha geniş yayılma ağları söz konusu olduğunda, VRRP gibi normal yedeklilik mekanizmalarının birçok dezavantajı vardır (trafik birden fazla kez üst üste gelir ...) OSPF'de yoktur.
-Küçük -yayın-etki alanları- yaklaşımını kullanmanın desteklenmesi için muhtemelen başka nedenler vardır .
Bence organizasyonun kapsamı çok önemli. Bir ağda toplam veya daha az toplam ana bilgisayar varsa ve trafiğin herhangi bir nedenle bölümlere ayrılması gerekmiyorsa, neden VLAN ve alt ağların karmaşıklığını eklemelisiniz? Ancak kapsam büyüdükçe, daha anlamlı olabilir.
Normalde olması gerekmeyen ağları ayırmak, bazı şeyleri daha kolaylaştırabilir. Örneğin, sunuculara güç sağlayan PDU'larımız sunucularla aynı VLAN veya alt ağdadır. Bu, sunucu yelpazemizde kullanılan güvenlik açığı tarama sistemimizin PDU’ları da taradığı anlamına gelir. Çok önemli bir şey değil, fakat taranacak PDU’lara ihtiyacımız yok. Ayrıca PDU'ların DHCP'yi yapılandırması çok acı verici oldukları için DHCP için iyi olurdu, ancak şu anda sunucularla aynı VLAN'da oldukları için bu pek mümkün değil.
PDU'lar için başka bir VLAN'a ihtiyacımız olmasa da, bazı şeyleri kolaylaştırabilir. Ve bu, çok daha uzun sürecek olan VLAN argümanına karşı daha fazla kazanıyor.
Ben, sadece anlam ifade ettiği yerde VLAN'lar olduğunu düşünüyorum. Örneğin, PDU'lara kendi VLAN'larını vermiş olsaydık, küçük cihaz gruplarına her zaman kendi VLAN'larını vermemiz gerektiği anlamına gelmez. Ancak bu durumda daha mantıklı olabilir. Bir grup cihazın kendi VLAN'ına sahip olması gerekmiyorsa ve bunu yapmanın avantajı yoksa, şeyleri olduğu gibi bırakmayı düşünebilirsiniz.