Tek bölgeli veri giriş bölgesi bağlantısı

Veri yönetimi giriş bölgesi, veri giriş bölgeleri ve bunların içindeki tüm hizmetler tek bölgeli bir kurulumda aynı bölgede ayarlanır. Tüm giriş bölgeleri aynı bağlantı hub'ı aboneliği içindedir. Bu abonelik, ağ sanal gereci (Azure güvenlik duvarı gibi), ExpressRoute ağ geçidi, sanal özel ağ (VPN) ağ geçidi, merkez sanal ağı veya sanal WAN (vWAN hub) içerebilen paylaşılan ağ kaynaklarını barındırıyor.

Şekil 1: Tek Bölge Bağlan üretkenlik.

Azure Ağ Hizmetleri'nin geçerli özelliklerine bağlı olarak, ağa bağlı bir ağ mimarisi kullanmanızı öneririz. Aralarında sanal ağ eşlemesi ayarlamanız gerekir:

• Bağlan ivity Hub ve Veri Yönetimi Bölgesi
• Bağlan Ivity Hub ve her Veri Giriş Bölgesi
• Veri Yönetimi Bölgesi ve her Veri Giriş Bölgesi
• Her Veri Giriş Bölgesi

Bu makalede, bulut ölçeğinde analiz için değerlendirdiğimiz her ağ mimarisi seçeneğinin avantajları ve dezavantajları açıklanmaktadır.

Bu makalenin ilk bölümü, Veri Yönetimi Bölgesi ve tüm Veri Giriş Bölgeleri'nin aynı bölgede barındırıldığı tek bölgeli bir desene odaklanır.

Her tasarım deseni aşağıdaki ölçütler kullanılarak değerlendirilir:

• Maliyet
• Kullanıcı erişim yönetimi
• Hizmet yönetimi
• Bant genişliği
• Gecikme süresi

Her tasarım seçeneğini aşağıdaki çapraz veri giriş bölgesi kullanım örneğini göz önünde bulundurarak analiz edeceğiz:

Not

B veri giriş bölgesinde barındırılan sanal makine B (VM B), A veri giriş bölgesinde barındırılan depolama hesabından bir veri kümesi yükler. Ardından VM B bu veri kümesini işler ve B veri giriş bölgesinde barındırılan B hesabı Depolama depolar.

Önemli

Bu makale ve ağ bölümündeki diğer makaleler, veri paylaşan iş birimlerini özetler. Ancak, bu ilk stratejiniz olmayabilir ve önce temel düzeyde başlamanız gerekebilir.

Ağınızı tasarlayarak sonunda veri giriş bölgeleri arasında önerilen kurulumu gerçekleştirebilirsiniz. Veri yönetimi giriş bölgelerinin idare için giriş bölgelerine doğrudan bağlı olduğundan emin olun.

Ağ ağ mimarisi (önerilir)

Bulut ölçeğinde analizi benimserken bir ağ ağı mimarisi kullanmanızı öneririz. Kiracınızda ayarlanan mevcut hub ve uç ağ tasarımına ek olarak, ağ ağı mimarisini uygulamak için iki şey yapmanız gerekir:

• Tüm veri giriş bölgesi sanal ağları arasına sanal ağ eşlemeleri ekleyin.
• Veri yönetimi giriş bölgenizle tüm veri giriş bölgeleri arasına sanal ağ eşleştirmeleri ekleyin.

Örnek senaryomuzda, Depolama Hesabı A'dan yüklenen veriler, iki veri giriş bölgesi sanal ağı arasında ayarlanmış bir sanal ağ eşleme bağlantısı (2) iletir. Vm B ((3) ve (4)) tarafından yüklenir ve işlenir, ardından B Hesabı'Depolama nda depolanmak üzere yerel Özel Uç Nokta (5) aracılığıyla gönderilir.

Bu senaryoda veriler Bağlan ivity Hub'ını geçmiyor. Veri yönetimi giriş bölgesi ve bir veya daha fazla veri giriş bölgesinden oluşan Veri Platformu içinde kalır.

Şekil 2: Ağ mimarisi.

Ağ mimarisinde kullanıcı erişim yönetimi

Ağ mimarisi tasarımında, veri uygulaması ekipleri yeni hizmetler oluşturabilmek için yalnızca iki şey gerektirir (Özel Uç Noktalar dahil):

• Veri giriş bölgesinde ayrılmış kaynak grubuna yazma erişimi
• Belirlenen alt ağlarına erişime katılma

Bu tasarımda, veri uygulaması ekipleri Özel Uç Noktaları kendileri dağıtabilir. Özel Uç Noktaları belirli bir uçtaki bir alt ağa bağlamak için gerekli erişim haklarına sahip oldukları sürece, ekiplerinizin gerekli bağlantıyı kurarken desteğe ihtiyacı yoktur.

Özet:

Ağ mimarisinde hizmet yönetimi

Ağ mimarisi tasarımında hiçbir ağ sanal gereci tek bir hata veya azaltma noktası işlevi görmez. Bağlan ivity Hub aracılığıyla gönderilen veri kümelerinin olmaması, bu sanal gerecin ölçeğini genişletmeniz gerekmemesi koşuluyla merkezi Azure platform ekibinizin ek yükünü azaltır.

Bu, merkezi Azure platformu ekibinin artık veri giriş bölgeleri arasında gönderilen tüm trafiği inceleyemeyecek ve günlüğe kaydedemiyebileceği anlamına gelir. Ancak bulut ölçeğinde analiz, birden çok aboneliği kapsayan uyumlu bir platformdur ve bu da ölçeklendirmeye olanak tanır ve platform düzeyindeki sınırlamaların üstesinden gelir ve bu da dezavantaj değildir.

Tek bir abonelikte barındırılan tüm kaynaklar sayesinde merkezi Azure platform ekibiniz artık merkezi Bağlan ivity Hub'daki tüm verileri de denetlemez. Ağ Güvenlik Grubu Akış Günlüklerini kullanarak ağ günlüklerini yakalamaya devam edebilirsiniz. Hizmete özgü Tanılama Ayarlar kullanarak diğer uygulama ve hizmet düzeyi günlüklerini birleştirebilir ve depolayabilirsiniz.

Tanılama ayarları için Azure İlkesi tanımlarını kullanarak bu günlüklerin tümünü uygun ölçekte yakalayabilirsiniz.

Bu tasarım, Özel DNS Bölgelerini temel alan bir Azure yerel DNS çözümü oluşturmanıza da olanak tanır. Özel DNS grupları için Azure İlkesi tanımları aracılığıyla DNS A kaydı yaşam döngüsünü otomatikleştirebilirsiniz.

Özet:

Ağ mimarisi maliyeti

Not

Eşlenmiş bir ağ üzerinden özel uç noktaya erişirken, sanal ağ eşlemesi için değil yalnızca özel uç noktanın kendisi için ücretlendirilirsiniz. Resmi açıklamayı SSS: Eşlenmiş bir ağdan özel uç noktaya erişirken faturalama nasıl çalışır? bölümünden okuyabilirsiniz.

Bu ağ tasarımında yalnızca şu ödemeler için ödemeniz olur:

• Özel Uç Noktalarınız (saat başına)
• Ham veri kümenizi (1) yüklemek ve işlenen veri kümenizi depolamak için Özel Uç Noktalarınız aracılığıyla gönderilen giriş ve çıkış trafiği (6)

Sanal ağ eşlemesi ücretlendirilmeyecektir (2), bu nedenle bu seçeneğin en düşük maliyeti vardır.

Özet:

Ağ mimarisinde bant genişliği ve gecikme süresi

Hiçbir ağ sanal gereçleri, çapraz veri giriş bölgesi veri değişimi için aktarım hızını sınırlamadığı için bu tasarımda bilinen bir bant genişliği veya gecikme süresi sınırlaması yoktur. Tasarımın tek sınırlayıcı faktörü, veri merkezlerimizin fiziksel sınırıdır (fiber optik kabloların hızı).

Özet:

Ağ mimarisi özeti

Bulut ölçeğinde analizi benimsemeyi planlıyorsanız, ağa bağlı ağ tasarımını kullanmanızı öneririz. Ağ ağ, en düşük maliyetle maksimum bant genişliği ve düşük gecikme süresi sunar, ancak kullanıcı erişim yönetimi veya DNS katmanıyla ilgili hiçbir ödün vermez.

Veri platformunda diğer ağ ilkelerini zorunlu kılmanız gerekiyorsa merkezi ağ sanal gereçleri yerine Ağ Güvenlik Grupları'nı kullanın.

Geleneksel merkez-uç mimarisi (önerilmez)

Merkez-uç ağ mimarisi tasarımı en belirgin seçenektir ve birçok işletmenin benimsediği bir seçenektir. İçinde ağ geçişi, Bağlan ivity Hub'ında, A Depolama Hesabı'ndaki verilere B VM'den erişmek için ayarlanır. Veriler iki sanal ağ eşlemesi ((2) ve (5)) ile Bağlan ivity Hub ((3) ve (4)) içinde barındırılan bir ağ sanal gerecinden geçer. Ardından veriler sanal makine (6) tarafından yüklenir ve B (8) Depolama Hesabına geri depolanır.

Şekil 3: Merkez-uç mimarisi.

Geleneksel merkez-uç mimarisinde kullanıcı erişim yönetimi

Geleneksel merkez-uç tasarımında, veri uygulama ekipleri yeni hizmetler oluşturabilmeleri için yalnızca iki şey gerektirir (Özel Uç Noktalar dahil):

• Veri giriş bölgesinde kaynak grubuna yazma erişimi
• Belirlenen alt ağlarına erişime katılma

Bu tasarımda, veri uygulaması ekipleri Özel Uç Noktaları kendileri dağıtabilir. Özel Uç Noktaları belirli bir uçtaki bir alt ağa bağlamak için gerekli erişim haklarına sahip oldukları sürece, ekiplerinizin gerekli bağlantıyı kurarken desteğe ihtiyacı yoktur.

Özet:

Geleneksel merkez-uç mimarisinde Hizmet Yönetimi

Bu ağ tasarımı iyi bilinir ve çoğu kuruluşun mevcut ağ kurulumuyla tutarlıdır. Bu, tasarımın açıklanmasını ve uygulanmasını kolaylaştırır. Azure kiracınızda FQDN çözümlemesi sağlamak için Özel DNS Bölgeleri ile merkezi bir Azure yerel DNS çözümü de kullanabilirsiniz. Özel DNS Bölgeleri'ni kullanmak, Azure İlkeleri aracılığıyla DNS A kaydı yaşam döngüsünü otomatikleştirmenizi sağlar.

Bu tasarımın bir diğer avantajı da trafiğin merkezi bir ağ sanal gereci üzerinden yönlendirilmesidir, bu nedenle bir Uçtan diğerine gönderilen ağ trafiği günlüğe kaydedilebilir ve denetlenebilir.

Bu tasarımın bir dezavantajı, merkezi Azure Platformu ekibinizin Rota Tablolarını el ile yönetmesi gerekir. Bu, birden çok veri giriş bölgesi arasında veri varlığı paylaşımını sağlayan Uçlar arasında geçiş sağlamak için gereklidir. Yol yönetimi zaman içinde karmaşık ve hataya eğilimli hale gelebilir ve önceden dikkate alınması gerekir.

Bu ağ kurulumunun bir diğer dezavantajı da merkezi ağ sanal gerecinizin kurulum şeklidir. Ağ sanal gereci tek bir hata noktası olarak çalışır ve bir hata oluşursa veri platformunda ciddi kapalı kalma süresine neden olabilir. Ayrıca bir veri platformunda veri kümesi boyutları arttıkça ve çapraz veri giriş bölgesi kullanım örnekleri arttıkça, merkezi ağ sanal gereci aracılığıyla daha fazla trafik gönderilir.

Zaman içinde bu, merkezi örnek üzerinden gigabaytlar, hatta terabaytlar halinde veri gönderilmesine neden olabilir. Mevcut ağ sanal gereçlerinin bant genişliği genellikle yalnızca bir veya iki basamaklı gigabayt aktarım hızıyla sınırlı olduğundan, merkezi ağ sanal gereci veri giriş bölgeleri arasındaki trafik akışını kritik ölçüde sınırlayan ve veri varlığı paylaşılabilirliğini sınırlayan bir performans sorununa dönüşebilir.

Bu sorundan kaçınmanın tek yolu, merkezi ağ sanal gerecinizin ölçeğini birden çok örnek arasında genişletmektir ve bu da bu tasarım için önemli maliyet etkilere neden olur.

Özet:

Geleneksel merkez-uç mimarisi maliyeti

Not

Eşlenmiş bir ağ üzerinden özel uç noktaya erişirken, sanal ağ eşlemesi için değil yalnızca özel uç noktanın kendisi için ücretlendirilirsiniz. Resmi açıklamayı SSS: Eşlenmiş bir ağdan özel uç noktaya erişirken faturalama nasıl çalışır? bölümünden okuyabilirsiniz.

Bu ağ için depolama hesaplarınızın Özel Uç Noktaları için saatlik ücretlendirilirsiniz. Ham veri kümesini (1) yüklemek ve işlenen veri kümesini (8) depolamak için Özel Uç Noktalar üzerinden gönderilen giriş ve çıkış trafiği için de ücretlendirilirsiniz.

Müşteriniz bir sanal ağ eşlemesinin (5) girişi ve çıkışı için ücretlendirilir. Daha önce belirtildiği gibi ilk sanal ağ eşlemesi ücretlendirilmiyor (2).

Bu ağ tasarımını ((3) ve (4) kullanıyorsanız yüksek bir merkezi ağ sanal gereci maliyetiyle sonuçlayacaksınız. Ek lisans satın alıp merkezi ağ sanal gerecinin ölçeğini isteğe bağlı olarak genişletmeniz veya Azure Güvenlik Duvarı gibi gigabayt başına işlenen ücreti ödemeniz gerekir.

Özet:

Geleneksel merkez-uç mimarisinde bant genişliği ve gecikme süresi

Bu ağ tasarımında ciddi bant genişliği sınırlamaları vardır. Platformunuz büyüdükçe merkezi ağ sanal gereci kritik bir performans sorunu haline gelir ve bu da veri kümeleri arası giriş bölgesi kullanım örneklerini ve veri kümesi paylaşımını sınırlar. Ayrıca büyük olasılıkla zaman içinde veri kümelerinin birden çok kopyasını oluşturur.

Bu tasarım, gerçek zamanlı analiz senaryolarında özellikle kritik hale gelen gecikme süresini de büyük ölçüde etkiler.

Özet:

Geleneksel merkez-uç mimarisi özeti

Bu merkez-uç ağ tasarımı erişim yönetimine ve bazı hizmet yönetimi avantajlarına sahiptir, ancak hizmet yönetimi ve bant genişliği ve gecikme süresiyle ilgili kritik sınırlamalar nedeniyle, bu ağ tasarımını çapraz veri giriş bölgesi kullanım örnekleri için öneremiyoruz.

Özel Uç Nokta projeksiyon mimarisi (önerilmez)

Bir diğer tasarım seçeneği de her giriş bölgesi genelinde Özel Uç Noktaların yansıtılıyor olmasıdır. Bu tasarımda, her giriş bölgesinde Depolama Hesabı A için bir Özel Uç Nokta oluşturulur. Bu, A veri giriş bölgesinde A veri giriş bölgesinde sanal ağa bağlı ilk Özel Uç Nokta'ya, B veri giriş bölgesindeki sanal ağa bağlı ikinci bir Özel Uç Noktaya vb. yol açar.

Aynı durum B hesabı Depolama ve potansiyel olarak veri giriş bölgeleri içindeki diğer hizmetler için de geçerlidir. Veri giriş bölgesi sayısını n olarak tanımlarsak, en azından tüm depolama hesapları ve potansiyel olarak veri giriş bölgeleri içindeki diğer hizmetler için n Özel Uç Nokta ile sonuçlarız. Bu, Özel Uç Nokta sayısında üstel bir artışa yol açar.

Şekil 4: Özel Uç Nokta projeksiyon mimarisi.

Belirli bir hizmetin tüm Özel Uç Noktaları (örneğin, Depolama A Hesabı) aynı FQDN'ye (örneğinstorageaccounta.privatelink.blob.core.windows.net) sahip olduğundan, bu çözüm DNS katmanında Özel DNS Bölgeleri kullanılarak çözülemez zorluklar oluşturur. Bunun yerine, istek sahibinin kaynağına/IP adresine göre DNS adlarını çözümleyebilecek özel bir DNS çözümüne ihtiyacınız vardır. Bu, VMA'nın A veri giriş bölgesindeki sanal ağa bağlı Özel Uç Noktalara bağlanmasını ve VM B'nin B veri giriş bölgesindeki sanal ağa bağlı Özel Uç Noktalara bağlanmasını sağlar. Bunu Windows Server tabanlı bir kurulumla yapabilirken, DNS A kayıtları yaşam döngüsünü Etkinlik Günlüğü ve Azure İşlevleri birleşimiyle otomatikleştirebilirsiniz.

Bu kurulumda, Depolama yerel Özel Uç Nokta (1) üzerinden veri kümesine erişerek A Hesabı A'daki ham veri kümesini VM B'ye yükleyebilirsiniz. Veri kümesini ((2) ve (3)) yükleyip işledikten sonra, yerel Özel Uç Noktaya (4) doğrudan erişerek B Hesabı'nda Depolama depolayabilirsiniz. Bu senaryoda, verilerin hiçbir sanal ağ eşlemesinde dolaşmaması gerekir.

Özel uç nokta projeksiyon mimarisinde kullanıcı erişim yönetimi

Bu tasarımın kullanıcı erişim yönetimi yaklaşımı, ağ mimarisine benzer. Ancak bu tasarımda, yalnızca belirli bir veri giriş bölgesi ve sanal ağ içinde değil, diğer veri giriş bölgelerinde ve ilgili sanal ağlarında da Özel Uç Noktalar oluşturmak için diğer veri giriş bölgeleri için erişim haklarına ihtiyacınız olabilir.

Bu nedenle, veri uygulama ekipleriniz yeni hizmetleri kendileri oluşturabilmek için iki şey değil üç şeye ihtiyaç duyar:

• Belirlenen veri giriş bölgesindeki bir kaynak grubuna yazma erişimi
• Belirlenen alt ağlarına erişime katılma
• İlgili yerel Özel Uç Noktaları oluşturmak için diğer tüm veri giriş bölgelerinin içindeki bir kaynak grubuna ve alt ağa erişim

Veri uygulama ekipleriniz her bir veri giriş bölgesinde izin gerektirdiğinden bu ağ tasarımı erişim yönetimi katmanınızın karmaşıklığını artırır. Tasarım ayrıca kafa karıştırıcı olabilir ve zaman içinde tutarsız RBAC'ye yol açabilir.

Veri giriş bölgesi ekiplerine ve veri uygulaması ekiplerine gerekli erişim hakları verilmezse, geleneksel merkez-uç mimarisinde açıklanan sorunlar (önerilmez) oluşur.

Özet:

Özel uç nokta projeksiyon mimarisinde hizmet yönetimi

Bu ağ tasarımı, ağ mimarisinin tasarımına benzer olsa da tek bir hata noktası veya azaltma aktarım hızı gibi davranan hiçbir ağ sanal gereci avantajına sahip değildir. Ayrıca, sanal gerecin ölçeğini genişletmeye gerek olmadığından veri kümelerini Bağlan ivity Hub üzerinden göndermeyerek merkezi Azure platform ekibiniz için yönetim yükünü azaltır. Bu, merkezi Azure platformu ekibinin artık veri giriş bölgeleri arasında gönderilen tüm trafiği inceleyemeyecek ve günlüğe kaydedemiyebileceği anlamına gelir. Ancak bulut ölçeğinde analiz, birden çok aboneliği kapsayan uyumlu bir platformdur ve bu da ölçeklendirmeye olanak tanır ve platform düzeyindeki sınırlamaların üstesinden gelir ve bu da dezavantaj değildir.

Tüm kaynaklar tek bir abonelikte barındırıldığında trafik merkezi Bağlan ivity Hub'ında incelenmez. Ağ Güvenlik Grubu Akış günlüklerini kullanarak ağ günlüklerini yakalamaya devam edebilir ve hizmete özgü Tanılama Ayarlar kullanarak diğer uygulama ve hizmet düzeyi günlüklerini birleştirebilir ve depolayabilirsiniz. Azure İlkeleri'ne tıklayarak bu günlüklerin tümünü uygun ölçekte yakalayabilirsiniz. Öte yandan, gerekli Özel Uç Noktalarda üstel artış nedeniyle veri platformunuzun gerektirdiği ağ adres alanı artar ve bu da en uygun değildir.

Bu ağ mimarisiyle ilgili en önemli endişeler, daha önce bahsedilen DNS zorluklarıdır. Azure yerel çözümünü Özel DNS Bölgeleri biçiminde kullanamazsınız, bu nedenle bu mimaride istek sahibinin kaynağı/IP adresi temelinde FQDN'leri çözümleyebilecek bir üçüncü taraf çözümü gerekir. Ayrıca, önerilen Azure İlkesi temelli çözümle karşılaştırıldığında yönetim yükünü önemli ölçüde artıran Özel DNS A kayıtlarını otomatikleştirmek için araçlar ve iş akışları geliştirmeniz ve bakımlarını da kullanmanız gerekir.

Özel DNS bölgeleri kullanarak dağıtılmış dns altyapısı oluşturabilirsiniz, ancak bu, kiracınızdaki diğer giriş bölgelerinde barındırılan özel bağlantı hizmetlerine erişmeye çalıştığınızda sorunlara neden olan DNS adaları oluşturur. Bu nedenle, bu tasarım uygulanabilir bir seçenek değildir.

Özet:

Özel uç nokta projeksiyon mimarisi maliyeti

Not

Eşlenmiş bir ağ üzerinden özel uç noktaya erişirken sanal ağ eşlemesi için değil yalnızca özel uç nokta için ücretlendirilirsiniz. Resmi açıklamayı SSS: Eşlenmiş bir ağdan özel uç noktaya erişirken faturalama nasıl çalışır? bölümünden okuyabilirsiniz.

Bu ağ tasarımında, ham veri kümelerini (1) yüklemek ve işlenen veri kümelerini depolamak için yalnızca Özel Uç Noktalar (saat başına) ve bu Özel Uç Noktalar aracılığıyla gönderilen giriş ve çıkış trafiği için ücretlendirilirsiniz (4). Ancak, veri platformunuzun Özel Uç Noktaları sayısındaki üstel artış nedeniyle ek maliyetler beklenmelidir. Saat başına ücretlendirildiğiniz için ek maliyet miktarı, kaç Özel Uç Nokta oluşturulduğuna bağlıdır.

Özet:

Özel uç nokta projeksiyon mimarisinde bant genişliği ve gecikme süresi

Veriler arası giriş bölgesi veri değişimi için aktarım hızını sınırlayan ağ sanal gereçleri olmadığından bu tasarımın bilinen bant genişliği ve gecikme süresi sınırlamaları yoktur. Tasarımın tek sınırlayıcı faktörü, veri merkezlerimizin fiziksel sınırıdır (fiber optik kabloların hızı).

Özet:

Özel Uç Nokta projeksiyon mimarisi özeti

Bu ağ mimarisinde Özel Uç Noktaların üstel büyümesi, hangi Özel Uç Noktaların hangi konumda hangi amaçla kullanıldığını izlemenize neden olabilir. Ayrıca erişim yönetimi sorunları ve DNS katmanı karmaşıklıkları da sınırlıdır. Bu sorunlar nedeniyle, bu ağ tasarımını çapraz veri giriş bölgesi kullanım örnekleri için öneremiyoruz.

Bağlan ivity Hub mimarisindeki Özel Uç Noktalar (önerilmez)

Bir diğer ağ seçeneği de Bağlan ivity Hub'ınızda Özel Uç Noktaları barındırmak ve bunları Hub sanal ağına bağlamaktır. Bu çözümde, kurumsal sanal ağınızdaki her hizmet için tek bir Özel Uç Nokta barındıracaksınız. Çoğu şirkette mevcut merkez-uç ağ mimarisi ve Bağlan ivity Hub'ınızın bu çözümde Özel Uç Noktalarınızı barındırması nedeniyle geçiş gerekli değildir. Bağlan ivity Hub'ınız ile veri giriş bölgeleri arasında sanal ağ eşlemesi doğrudan erişim sağlar.

Veriler, Bağlan ivity Hub ile veri giriş bölgesi arasında tek bir sanal ağ eşlemesi geçirerek B vm'sindeki Depolama Hesap A'da depolanan bir veri kümesini yükler. Bu veri kümesi yüklendikten ve işlendikten ((3) ve (4)) sonra aynı sanal ağ eşlemesini ikinci kez (5) geçer ve son olarak Hub Vnet'e (6) bağlı Özel Uç Nokta üzerinden Depolama Hesap B'de depolanır.

Şekil 5: Bağlan Ivity Hub mimarisindeki Özel Uç Noktalar.

Bağlan ivity Hub mimarisinde kullanıcı erişim yönetimi

Bu ağ tasarımında, veri giriş bölgesi ekiplerinizin ve veri uygulama ekiplerinizin Özel Uç Noktaları Hub sanal ağına bağlayabilmesi için iki şey gerekir:

• Bağlan Ivity Hub aboneliğinizdeki bir kaynak grubuna izin yazma
• Hub sanal asına katılma izinleri

Bağlan ivity Hub'ınız kuruluşunuzun Azure platform ekibi için tasarlanmıştır ve kuruluşunuzun gerekli ve paylaşılan ağ altyapısını (güvenlik duvarları, ağ geçitleri ve ağ yönetimi araçları dahil) barındırmak için ayrılmıştır. Bu ağ seçeneği, Kurumsal Ölçekli Giriş Bölgesi temel ilkelerinden erişim yönetimi ilkelerine uymadığından bu tasarımı tutarsız hale getirir. Bu nedenle, çoğu Azure platform ekibi bu tasarım seçeneğini onaylamaz.

Özet:

Bağlan ivity Hub mimarisinde hizmet yönetimi

Ağ mimarisinin tasarımına benzer olsa da, bu tasarımda tek bir hata noktası veya azaltma aktarım hızı gibi davranan bir ağ sanal gereci yoktur. Ayrıca, sanal gerecin ölçeğini genişletmeye gerek olmadığından veri kümelerini Bağlan ivity Hub üzerinden göndermeyerek merkezi Azure platform ekibiniz için yönetim yükünü azaltır. Bu, merkezi Azure platformu ekibinin artık veri giriş bölgeleri arasında gönderilen tüm trafiği inceleyemeyecek ve günlüğe kaydedemiyebileceği anlamına gelir. Ancak bulut ölçeğinde analiz, birden çok aboneliği kapsayan uyumlu bir platformdur ve bu da ölçeklendirmeye olanak tanır ve platform düzeyindeki sınırlamaların üstesinden gelir ve bu da dezavantaj değildir.

Tüm kaynaklar tek bir abonelikte barındırıldığında trafik merkezi Bağlan ivity Hub'ında incelenmez. Ağ Güvenlik Grubu Akış günlüklerini kullanarak ağ günlüklerini yakalamaya devam edebilir ve hizmete özgü Tanılama Ayarlar kullanarak diğer uygulama ve hizmet düzeyi günlüklerini birleştirebilir ve depolayabilirsiniz. Azure İlkeleri'ne tıklayarak bu günlüklerin tümünü uygun ölçekte yakalayabilirsiniz.

Bu tasarım, Özel DNS Bölgelerini temel alan bir Azure yerel DNS çözümü oluşturmanıza ve Azure İlkeleri aracılığıyla DNS A kaydı yaşam döngüsünü otomatikleştirmenize de olanak tanır.

Özet:

Bağlan Ivity Hub mimari maliyeti

Not

Eşlenmiş bir ağ üzerinden özel uç noktaya erişirken, sanal ağ eşlemesi için değil yalnızca özel uç noktanın kendisi için ücretlendirilirsiniz. Resmi açıklamayı SSS: Eşlenmiş bir ağdan özel uç noktaya erişirken faturalama nasıl çalışır? bölümünden okuyabilirsiniz.

Bu ağ tasarımında, ham veri kümesini (1) yüklemek ve işlenen veri kümesini (6) depolamak için yalnızca Özel Uç Noktalarınız (saat başına) ve bu Özel Uç Noktalar aracılığıyla gönderilen giriş ve çıkış trafiği için ücretlendirilirsiniz.

Özet:

Bağlan ivity Hub mimarisinde bant genişliği ve gecikme süresi

Veriler arası giriş bölgesi veri değişimi için aktarım hızını sınırlayan ağ sanal gereçleri olmadığından bu tasarımın bilinen bant genişliği ve gecikme süresi sınırlamaları yoktur. Tasarımın tek sınırlayıcı faktörü, veri merkezlerimizin fiziksel sınırıdır (fiber optik kabloların hızı).

Özet:

Bağlan ivity Hub mimarisinde Özel Uç Noktalar özeti

Bu ağ mimarisi tasarımının birden çok avantajı olsa da, daha önce bahsedilen erişim yönetimi tutarsızlıkları onu alt bölüm yapar. Bu nedenle, bu tasarım yaklaşımını öneremiyoruz.

Tek bölgeli veri giriş bölgesi bağlantı sonucu

Gözden geçirilmiş tüm ağ mimarisi seçenekleri ve bunların artıları ve dezavantajları arasında net kazanan ağ mimarisidir . Aktarım hızı ve maliyet ve yönetim açısından muazzam avantajlara sahiptir. Bu nedenle bulut ölçeğinde analiz dağıtırken kullanmanızı öneririz. Eşleme uç sanal ağları daha önce yaygın değildi ve bu durum veri kümelerini etki alanları ve iş birimleri arasında paylaşmayla ilgili sorunlara yol açtı.

Bulut ölçeği analizini birden çok aboneliğe yayılan tutarlı bir çözüm olarak görüntüleyebilirsiniz. Tek bir abonelik kurulumunda ağ trafiği akışı, ağ mimarisindeki akışa eşittir. Tek bir abonelik kurulumunda, kullanıcılar büyük olasılıkla bulut ölçeğinde analizin önlemeyi hedeflediği abonelik düzeyi sınırlarına ve kotalarına isabet edecektir.

Sonraki adımlar

• Bölgeler arası veri giriş bölgesi Bağlan