Azure Yerel'in bulut dağıtımları için ağ ile ilgili dikkat edilmesi gerekenler

Şunlar için geçerlidir: Azure Yerel'in hiper yakınsanmış dağıtımları

Bu makalede, bulut dağıtımı için azure yerel sistem ağı tasarlama ve planlama adımları anlatılmaktadır. Devam etmeden önce çeşitli Azure Yerel ağ desenleri ve kullanılabilir yapılandırmalar hakkında bilgi sahibi olun.

Ağ tasarım çerçevesi

Aşağıdaki diyagramda Azure Yerel örneğinin ağ tasarım çerçevesini tanımlayan çeşitli kararlar ve adımlar gösterilmektedir: küme boyutu, küme depolama bağlantısı, ağ trafiği amaçları, yönetim bağlantısı ve ağ bağdaştırıcısı yapılandırması. Her tasarım kararı, sonraki adımlarda sağlanan tasarım seçeneklerini etkinleştirir veya izin verir:

1. Adım: Küme boyutunu belirleme

Ağ karar çerçevesini gösteren diyagram.

Azure Yerel örneğinizin boyutunu belirlemeye yardımcı olmak için Azure Yerel boyutlayıcı aracını kullanın. Burada sanal makine sayısı (VM), VM'lerin boyutu ve Azure Sanal Masaüstü, SQL Server veya AKS gibi VM'lerin iş yükü kullanımı gibi profilinizi tanımlayabilirsiniz.

Azure Yerel makine gereksinimleri makalesinde açıklandığı gibi, Azure Yerel örneğinde desteklenen makine sayısı üst sınırı 16'dır. İş yükü kapasite planlamanızı tamamladıktan sonra, altyapınızda iş yüklerini çalıştırmak için gereken makine düğümlerinin sayısını iyi anlamanız gerekir.

• İş yükleriniz dört veya daha fazla düğüm gerektiriyorsa: Depolama ağ trafiği için anahtarsız yapılandırma dağıtamaz ve kullanamazsınız. Depolama trafiğini işlemek için Uzaktan Doğrudan Bellek Erişimi (RDMA) desteğine sahip bir fiziksel anahtar eklemeniz gerekir. Azure Yerel örneği ağ mimarisi hakkında daha fazla bilgi için Ağ başvuru desenlerine genel bakış sayfasına bakın.

• İş yükleriniz üç veya daha az düğüm gerektiriyorsa: Depolama bağlantısı için anahtarsız veya anahtarlı yapılandırmalar seçebilirsiniz.

• Daha sonra ölçeği üçten fazla düğüme genişletmeyi planlıyorsanız, depolama ağ trafiği için fiziksel bir anahtar kullanmanız gerekir. Anahtarsız dağıtımlar için herhangi bir ölçek genişletme işlemi, Microsoft'un Azure Local için yazılım geliştirme döngüsünde etkin olarak doğrulamadığı düğümler arasında ağ kablonuzun elle yapılandırılmasını gerektirir.

Küme boyutu kararı için özetlenmiş noktalar şunlardır:

Karar	Dikkat edilmesi gereken noktalar
Küme boyutu (küme başına düğüm sayısı)	Azure portalı veya Azure Resource Manager şablonları aracılığıyla anahtarsız yapılandırma yalnızca 1, 2 veya 3 düğüm kümesi için kullanılabilir. 4 veya daha fazla düğüme sahip kümeler, depolama ağı trafiği için fiziksel anahtar gerektirir.
Ölçeklendirme gereksinimleri	Düzenleyiciyi kullanarak kümenizin ölçeğini genişletmeyi planlıyorsanız, depolama ağı trafiği için fiziksel bir anahtar kullanmanız gerekir.

2. Adım: Küme depolama bağlantısını belirleme

Fiziksel ağ gereksinimleri bölümünde açıklandığı gibi Azure Local, depolama ağ trafiği için iki tür bağlantıyı destekler:

• Trafiği işlemek için fiziksel bir ağ anahtarı kullanın.
• Depolama trafiği için çapraz ağ veya fiber kablolarla düğümleri aralarında doğrudan bağlayın.

Her seçeneğin avantajları ve dezavantajları yukarıdaki makalede belgelenmiştir.

Daha önce belirtildiği gibi, iki seçenek arasında yalnızca kümenizin boyutu üç veya daha az düğüm olduğunda karar vekleyebilirsiniz. Dört veya daha fazla düğüme sahip tüm kümeler, depolama için bir ağ anahtarı kullanılarak otomatik olarak dağıtılır.

Kümelerin üçten az düğümü varsa, depolama bağlantısı kararı bir sonraki adımda tanımlayabileceğiniz ağ amaçlarının sayısını ve türünü etkiler.

Örneğin, anahtarsız yapılandırmalar için iki ağ trafiği amacı tanımlamanız gerekir. Çapraz kabloları kullanan doğu-batı iletişimleri için depolama trafiğinin kuzey-güney bağlantısı yoktur ve ağ altyapınızın geri kalanından tamamen yalıtılmış olur. Bu, yönetim için giden bağlantı ve hesaplama iş yükleriniz için ikinci bir ağ amacı tanımlamanız gerektiği anlamına gelir.

Her ağ amacını tek bir fiziksel ağ bağdaştırıcısı bağlantı noktasıyla tanımlamak mümkün olsa da, hataya dayanıklılık sağlamaz. Bu nedenle, her ağ amacı için her zaman en az iki fiziksel ağ bağlantı noktası kullanmanızı öneririz. Depolama için bir ağ anahtarı kullanmaya karar verirseniz, depolama dahil olmak üzere tüm ağ trafiğini hiper yakınsanmış veya tamamen yakınsanmış konak ağ yapılandırması olarak da bilinen tek bir ağ amacında gruplandırabilirsiniz.

Küme depolama bağlantısı kararı için özetlenen noktalar şunlardır:

Karar	Dikkat edilmesi gereken noktalar
Depolama için anahtar yok	Azure portalı veya Resource Manager şablon dağıtımı aracılığıyla anahtarsız yapılandırma yalnızca 1, 2 veya 3 düğüm kümesi için desteklenir. Azure portalı veya Resource Manager şablonları kullanılarak 1 veya 2 düğüm depolama anahtarsız kümeleri dağıtılabilir. 3 düğüm depolama anahtarsız kümeleri yalnızca Resource Manager şablonları kullanılarak dağıtılabilir. Ölçek genişletme işlemleri, anahtarsız dağıtımlarda desteklenmez. Dağıtımdan sonra düğüm sayısında yapılan herhangi bir değişiklik için el ile yapılandırma gerekir. Depolama anahtarsız yapılandırması kullanılırken en az 2 ağ amacı gerekir.
Depolama için ağ anahtarı	Düzenleyiciyi kullanarak kümenizin ölçeğini genişletmeyi planlıyorsanız, depolama ağı trafiği için fiziksel bir anahtar kullanmanız gerekir. Bu mimariyi 1 ile 16 arasında istediğiniz sayıda düğümle kullanabilirsiniz. Zorunlu tutulmasa da, tüm ağ trafiği türleriniz (Yönetim, İşlem ve Depolama) için tek bir amaç kullanabilirsiniz

Aşağıdaki diyagramda çeşitli dağıtımlar için kullanabileceğiniz depolama bağlantısı seçenekleri özetlenmiştir:

3. Adım: Ağ trafiği amaçlarını belirleme

Azure Yerel için tüm dağıtımlar konak ağ yapılandırması için Ağ ATC'sini kullanır. Ağ amaçları, Azure portalı aracılığıyla Azure Yerel'i dağıtırken otomatik olarak yapılandırılır. Ağ amaçları ve bunların sorunlarını giderme hakkında daha fazla bilgi edinmek için bkz . Ortak ağ ATC komutları.

Bu bölümde, tasarım kararınızın ağ trafiği amaçlarına etkileri ve çerçevenin bir sonraki adımını nasıl etkilediği açıklanmaktadır. Bulut dağıtımları için, ağ trafiğinizi bir veya daha fazla amaç halinde gruplandırmak için dört seçenek arasından seçim yapabilirsiniz. Kullanılabilir seçenekler, kümenizdeki düğüm sayısına ve kullanılan depolama bağlantı türüne bağlıdır.

Kullanılabilir ağ amacı seçenekleri aşağıdaki bölümlerde ele alınmaktadır.

Ağ amacı: Tüm trafiği gruplandırma

Ağ ATC, yönetim, hesaplama ve depolama ağ trafiğini içeren benzersiz bir niyet yapılandırıyor. Bu amada atanan ağ bağdaştırıcıları, tüm ağ trafiği için bant genişliğini ve aktarım hızını paylaşır.

• Bu seçenek, depolama trafiği için fiziksel bir anahtar gerektirir. Geçişsiz bir mimariye ihtiyacınız varsa, bu tür bir niyeti kullanamazsınız. Depolama bağlantısı için anahtarsız bir yapılandırma seçerseniz Azure portalı bu seçeneği otomatik olarak filtreler.

• Yüksek Kullanılabilirlik sağlamak için en az iki ağ bağdaştırıcısı bağlantı noktası önerilir.

• Depolama için RDMA trafiğini desteklemek için en az 10 Gb/sn ağ arabirimi gerekir.

Ağ amacı: Grup yönetimi ve işlem trafiği

Network ATC'de iki niyet yapılandırılır. İlk amaç yönetim ve işlem ağ trafiğini, ikinci amaç ise yalnızca depolama ağ trafiğini içerir. Her bir amaç için farklı bir ağ bağdaştırıcısı bağlantı noktaları seti olmalıdır.

Şu durumda hem anahtarlı hem de anahtarsız depolama bağlantısı için bu seçeneği kullanabilirsiniz:

• Yüksek kullanılabilirlik sağlamak amacıyla her amaç için en az iki ağ bağdaştırıcısı bağlantı noktası kullanılabilir.

• Depolama için ağ anahtarını kullanırsanız, RDMA için fiziksel bir anahtar kullanılır.

• Depolama için RDMA trafiğini desteklemek için en az 10 Gb/sn ağ arabirimi gerekir.

Ağ amacı: İşlem ve depolama trafiğini gruplandırma

Network ATC'de iki niyet yapılandırılır. İlk amaç işlem ve depolama ağ trafiğini, ikinci amaç ise yalnızca yönetim ağ trafiğini içerir. Her amaç farklı bir ağ bağdaştırıcısı bağlantı noktası kümesi kullanmalıdır.

• Aynı bağlantı noktaları işlem trafiğiyle paylaşıldığından, bu seçenek depolama trafiği için fiziksel bir anahtar gerektirir ve bu da kuzey-güney iletişimi gerektirir. Anahtarsız yapılandırmaya ihtiyacınız varsa, bu tür bir amacı kullanamazsınız. Depolama bağlantısı için anahtarsız bir yapılandırma seçerseniz Azure portalı bu seçeneği otomatik olarak filtreler.

• Bu seçenek RDMA için fiziksel bir anahtar gerektirir.

• Yüksek kullanılabilirlik sağlamak için en az iki ağ bağdaştırıcısı bağlantı noktası önerilir.

• RDMA trafiğini desteklemek için işlem ve depolama amacı için en az 10 Gb/sn ağ arabirimi önerilir.

• Yönetim amacı, işlem amacı olmadan bildirildiğinde bile, Ağ ATC, yönetim ağına yüksek erişilebilirlik sağlamak amacıyla, Gömülü Anahtar Ekip Oluşturma (SET) sanal anahtarı oluşturur.

Ağ amacı: Özel yapılandırma

Amaçlardan en az biri yönetim trafiğini içerdiği sürece kendi yapılandırmanızı kullanarak en fazla üç amaç tanımlayın. İkinci bir işlem amacına ihtiyacınız olduğunda bu seçeneği kullanmanızı öneririz. Bu ikinci işlem amacı gereksinimi senaryoları arasında uzak depolama trafiği, VM'lerin yedekleme trafiği veya farklı iş yükü türleri için ayrı bir işlem amacı yer alır.

• Depolama amacı diğer amaçlardan farklıysa hem anahtarlanmış hem de anahtarsız depolama bağlantısı için bu seçeneği kullanın.

• Başka bir işlem amacı gerektiğinde veya farklı ağ bağdaştırıcıları üzerinden farklı trafik türlerini tamamen ayırmak istediğinizde bu seçeneği kullanın.

• Yüksek kullanılabilirlik sağlamak için her amaç için en az iki ağ bağdaştırıcısı bağlantı noktası kullanın.

• RDMA trafiğini desteklemek için işlem ve depolama amacı için en az 10 Gb/sn ağ arabirimi önerilir.

Aşağıdaki diyagramda çeşitli dağıtımlar için kullanabileceğiniz ağ amacı seçenekleri özetlenmiştir:

4. Adım: Yönetim ve depolama ağ bağlantısını belirleme

Bu adımda altyapı alt ağ adres alanını, bu adreslerin kümenize nasıl atanacaklarını ve İnternet'e ve Etki Alanı Adı Sistemi (DNS) veya Active Directory Hizmetleri gibi diğer intranet hizmetlerine giden bağlantı için düğümler için herhangi bir ara sunucu veya VLAN kimliği gereksinimi olup olmadığını tanımlarsınız.

Yönlendirme, güvenlik duvarı veya alt ağ gereksinimlerini tahmin edebilmeniz için dağıtıma başlamadan önce aşağıdaki altyapı alt ağ bileşenlerinin planlanması ve tanımlanması gerekir.

Azure Yerel altyapı bileşenleri için kaçınmanız gereken Arc Kaynak Köprüsü rezervli IP aralıkları

Azure Yerel'i dağıttığınızda sistem, Azure Kaynak Köprüsü (ARB) ve AKS'yi destekleyen iç Kubernetes hizmetleri için belirli IP adresi aralıklarını otomatik olarak bir kenara ayarlar. Azure Yerel yapılandırmanız bu ayrılmış aralıklarla çakışan IP'ler kullanıyorsa dağıtımınız başarısız olabilir veya sorun gidermesi zor bağlantı sorunlarıyla karşılaşabilir.

Ayrılmış aralıklar - Kullanmayın

Aşağıdaki IP aralıkları Arc Kaynak Köprüsü için dahili olarak ayrılmıştır ve aşağıda listelenen azure yerel altyapı bileşenleri için kullanılmamalıdır:

Ayrılmış aralık	Kullanım amacı
10.96.0.0/12	Kubernetes iç hizmetleri (küme IP'leri)
10.244.0.0/16	Kubernetes pod ağı

Dağıtımdan önce kontrol edilecekler

Aşağıdaki Azure Yerel altyapı IP'lerinden hiçbirinin yukarıdaki ayrılmış aralıklara uymadığından emin olun:

Bunu denetleyin	Sorun örneği
DNS sunucu IP'leriniz	DNS şu konumda 10.96.1.10 çakışacak
Ara sunucu IP'niz	konumundaki 10.97.10.25 ara sunucu çakışacak
Altyapı IP havuzunuz	Havuz başlangıçta 10.100.0.1 içinde 10.96.0.0/12 yer alır
Yönetim düğüm IP'leriniz	10.244.1.50 düğümü ağ ile çakışıyor
Varsayılan ağ geçidiniz	konumundaki 10.96.0.1 ağ geçidi çakışıyor
VM'ler için herhangi bir mantıksal ağ	VM alt ağı 10.244.100.0/24 pod ağıyla çakışıyor

Kullanılacak güvenli IP aralıkları

Aşağıda, çakışmayacak yaygın olarak kullanılan özel IP aralıklarının örnekleri verilmiştir:

Güvenli aralık	Notes
192.168.x.x	Küçük dağıtımlar için en yaygın kullanılanlar
172.16.x.x'dan 172.31.x.x'e	Orta ölçekli ağlar için iyi
10.0.x.x'dan 10.95.x.x'e	Güvenli — ayrılmış 10.96.0.0 sınırın altında kalır
10.112.x.x ve üzeri	Güvenli — ayrılmış 10.111.255.255 sınırın üzerinde

İlgili içerik

• AKS için IP adresi planlama gereksinimleri
• Arc kaynak köprüsü için belirlenmiş IP aralıkları

Ağ bağdaştırıcısı sürücüleri

İşletim sistemini yükledikten sonra ve düğümlerinizde ağ yapılandırmadan önce, ağ bağdaştırıcılarınızın OEM veya ağ arabirimi satıcınız tarafından sağlanan en son sürücüye sahip olduğundan emin olmanız gerekir. Varsayılan Microsoft sürücüleri kullanıldığında ağ bağdaştırıcılarının önemli özellikleri açığa çıkmayabilir.

Yönetim IP havuzu

Azure Yerel örneğinizin ilk dağıtımını yaparken, varsayılan olarak dağıtılan altyapı hizmetleri için ardışık IP'lerden oluşan bir IP aralığı tanımlamanız gerekir.

Aralığın geçerli ve gelecekteki altyapı hizmetleri için yeterli IP'ye sahip olduğundan emin olmak için en az altı ardışık kullanılabilir IP adresi aralığı kullanmanız gerekir. Bu adresler küme IP'si, Azure Kaynak Köprüsü VM'si ve bileşenleri için kullanılır.

Altyapı ağında diğer hizmetleri çalıştırmayı düşünüyorsanız havuza ek bir altyapı IP'leri arabelleği atamanızı öneririz. Başlangıçta planladığınız havuzun boyutu tükenirse PowerShell kullanarak altyapı ağı için dağıtımdan sonra başka IP havuzları da ekleyebilirsiniz.

Dağıtım sırasında, ortam denetleyicisi Yönetim IP Havuzu adreslerinden Yönetim IP Havuzu varsayılan ağ geçidine ICMP bağlantısını test eder. Varsayılan ağ geçidinizin Azure Yerel Yönetim alt ağından gelen ICMP trafiğine izin verdiğinden emin olun.

Dağıtım sırasında altyapı alt ağı için IP havuzunuzu tanımlarken aşağıdaki koşulların karşılanması gerekir:

#	Koşul
1	IP aralığı ardışık IP'ler kullanmalıdır ve tüm IP'ler bu aralık içinde kullanılabilir olmalıdır. Bu IP aralığı dağıtımdan sonra değiştirilemez.
2	IP aralığı küme düğümü yönetim IP'lerini içermemelidir, ancak düğümlerinizle aynı alt ağda olmalıdır.
3	Yönetim IP havuzu için tanımlanan varsayılan ağ geçidinin İnternet'e giden bağlantı sağlaması gerekir.
4	DNS sunucuları Active Directory ve internet ile ad çözümlemesi sağlamalıdır.
5	Yönetim IP'leri giden İnternet erişimi gerektirir.
6	Ortam denetleyicisi, ICMP trafiğinin Azure Yerel yönetim IP havuzu aralığından varsayılan ağ geçidinde yanıt verdiğini doğrular.

Yönetim VLAN Kimliği

Azure Yerel örneğinizin yönetim alt bilgisayarınızda çoğu durumda VLAN Kimliği 0 olarak bildirilen varsayılan VLAN'ın kullanılması önerilir. Ancak, ağ gereksinimleriniz altyapı ağınız için belirli bir yönetim VLAN'ını kullanmaksa, yönetim trafiği için kullanmayı planladığınız fiziksel ağ bağdaştırıcılarınızda yapılandırılmalıdır.

Yönetim için iki fiziksel ağ bağdaştırıcısı kullanmayı planlıyorsanız, her iki bağdaştırıcıda da VLAN'ı ayarlamanız gerekir. Bu işlem, makinelerinizin bootstrap yapılandırmasının bir parçası olarak ve bu VLAN'ı kullanarak düğümleri başarıyla kaydettiğinizden emin olmak için Azure Arc'a kaydedilmeden önce yapılmalıdır.

Fiziksel ağ bağdaştırıcılarında VLAN kimliğini ayarlamak için aşağıdaki PowerShell komutunu kullanın:

Bu örnek, fiziksel ağ bağdaştırıcısında VLAN ID 44'i yapılandırıyor NIC1.

Set-NetAdapter -Name "NIC1" -VlanID 44

VLAN Kimliği ayarlandıktan ve düğümlerinizin IP'leri fiziksel ağ bağdaştırıcılarında yapılandırıldıktan sonra, düzenleyici bu VLAN kimliği değerini yönetim için kullanılan fiziksel ağ bağdaştırıcısından okur ve depolar, böylece Azure Kaynak Köprüsü VM'si veya dağıtım sırasında gereken diğer altyapı VM'leri için kullanılabilir. Azure portalından bulut dağıtımı sırasında yönetim VLAN kimliğini ayarlamak mümkün değildir, çünkü fiziksel anahtar VLAN'ları düzgün yönlendirilmezse düğümler ile Azure arasındaki bağlantıyı kesme riski taşır.

Sanal anahtar ile Yönetim VLAN Kimliği

Bazı senaryolarda, dağıtım başlamadan önce sanal anahtar oluşturma gereksinimi vardır.

Not

Sanal anahtar oluşturmadan önce Hype-V rolünü etkinleştirdiğinizden emin olun. Daha fazla bilgi için Gerekli Windows rolünü yükleme bölümüne bakın.

Sanal anahtar yapılandırması gerekiyorsa ve belirli bir VLAN kimliği kullanmanız gerekiyorsa şu adımları izleyin:

1. Önerilen adlandırma kuralıyla sanal anahtar oluşturma

Azure Yerel dağıtımları, yönetim, işlem ve depolama amaçları için sanal anahtarları ve sanal ağ bağdaştırıcılarını oluşturmak ve yapılandırmak için Ağ ATC'sini temel alır. Varsayılan olarak, Ağ ATC amaçlar için sanal anahtarı oluşturduğunda, sanal anahtar için belirli bir ad kullanır.

Sanal anahtar adlarınızı aynı adlandırma kuralıyla adlandırmanızı öneririz. Sanal anahtarlar için önerilen ad aşağıdaki gibidir:

"ConvergedSwitch($IntentName)", burada $IntentName dağıtım sırasında portala yazılan amacın adıyla eşleşmelidir. Bu dize, bir sonraki adımda açıklandığı gibi yönetim için kullanılan sanal ağ bağdaştırıcısının adıyla da eşleşmelidir.

Aşağıdaki örnekte, önerilen adlandırma kuralını $IntentName kullanarak PowerShell ile sanal anahtarın nasıl oluşturulacağı gösterilmektedir. Ağ bağdaştırıcısı adlarının listesi, yönetim ve işlem ağ trafiği için kullanmayı planladığınız fiziksel ağ bağdaştırıcılarının listesidir:

$IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true

Not

Azure Yerel örneği dağıtıldıktan sonra yönetim amacının veya sanal anahtar adının değiştirilmesi desteklenmez. Dağıtımdan sonra amacı güncelleştirmeniz veya yeniden oluşturmanız gerekiyorsa aynı amaç adını ve sanal anahtar adını kullanmanız gerekir.

2. Tüm düğümler için gerekli Ağ ATC adlandırma kuralını kullanarak yönetim sanal ağ bağdaştırıcısını yapılandırma

Sanal anahtar ve ilişkili yönetim sanal ağ bağdaştırıcısı oluşturulduktan sonra, ağ bağdaştırıcısı adının Ağ ATC adlandırma standartlarıyla uyumlu olduğundan emin olun.

Özellikle, yönetim trafiği için kullanılan sanal ağ bağdaştırıcısının adı aşağıdaki kuralları kullanmalıdır:

• Ağ bağdaştırıcısının ve sanal ağ bağdaştırıcısının adı vManagement($intentname) kullanmalıdır.
• Bu ad büyük/küçük harfe duyarlıdır.
• $Intentname herhangi bir dize olabilir, ancak sanal anahtar için kullanılan adla aynı olmalıdır. Amaç adını tanımlarken Azure portalında aynı dizeyi kullandığınızdan Mgmt emin olun.

Yönetim sanal ağ bağdaştırıcısı adını güncelleştirmek için aşağıdaki komutları kullanın:

$IntentName = "MgmtCompute"

#Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"

#Rename NetAdapter because during creation, Hyper-V adds the string "vEthernet" to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"

Not

Dağıtım doğrulaması sırasında düğümlerdeki tüm vSwitch'lerin karşılık gelen vNIC'leri olmalıdır. VSwitch'ler varsa ancak eşleşen vNIC'ler yoksa, işlem aşağıdaki hatayla başarısız olur:
"İşlem tamamlanamadı. 200: Düğümlerde vSwitch'ler var, ancak vnic yok, bu senaryo desteklenmiyor."
Get-NetAdapter ve Get-VMNetworkAdapter -ManagementOS çıkışları arasındaki bağdaştırıcı adlarının eşleştiğinden emin olun. Eşleşmiyorsa dağıtımı yeniden denemeden önce NIC'leri yeniden adlandırın.

3. VLAN Kimliğini tüm düğümler için sanal ağ bağdaştırıcısını yönetecek şekilde yapılandırma

Sanal anahtar ve yönetim sanal ağ bağdaştırıcısı oluşturulduktan sonra, bu bağdaştırıcı için gerekli VLAN kimliğini belirtebilirsiniz. Sanal ağ bağdaştırıcısına VLAN kimliği atamak için farklı seçenekler olsa da, desteklenen tek seçenek komutunu kullanmaktır Set-VMNetworkAdapterIsolation .

Gerekli VLAN Kimliği yapılandırıldıktan sonra, ip adresini ve ağ geçitlerini yönetim sanal ağ bağdaştırıcısına atayarak diğer düğümler, DNS, Active Directory ve İnternet ile bağlantısı olduğunu doğrulayabilirsiniz.

Aşağıdaki örnekte, yönetim sanal ağ bağdaştırıcısının varsayılan yerine VLAN Kimliğini 8 kullanacak şekilde nasıl yapılandırılır gösterilmektedir:

Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID "8"

4. Dağıtım sırasında yönetim amacı için fiziksel ağ bağdaştırıcılarına başvurun

Yeni oluşturulan sanal ağ bağdaştırıcısı, Azure portalı aracılığıyla dağıtım yaparken kullanılabilir olarak gösteriliyor olsa da, ağ yapılandırmasının Ağ ATC'sini temel alarak olduğunu unutmamanız önemlidir. Bu, yönetimi veya yönetim ve işlem amacını yapılandırırken bu amaç için kullanılan fiziksel ağ bağdaştırıcılarını seçmemiz gerektiği anlamına gelir.

Not

Ağ amacı için sanal ağ bağdaştırıcısını seçmeyin.

Aynı mantık Azure Resource Manager şablonları için de geçerlidir. Ağ amaçları için kullanmak istediğiniz fiziksel ağ bağdaştırıcılarını belirtmeniz ve hiçbir zaman sanal ağ bağdaştırıcılarını belirtmemelisiniz.

VLAN kimliğiyle ilgili özetlenmiş noktalar şunlardır:

#	Dikkat edilmesi gereken noktalar
1	Makineleri Azure Arc'a kaydetmeden önce yönetim için fiziksel ağ bağdaştırıcısında VLAN kimliği belirtilmelidir.
2	Makineleri Azure Arc'a kaydetmeden önce sanal anahtar gerektiğinde belirli adımları kullanın.
3	Yönetim VLAN Kimliği, dağıtım sırasında konak yapılandırmasından altyapı VM'lerine taşınır.
4	Azure portalı dağıtımı veya Resource Manager şablon dağıtımı için VLAN kimliği giriş parametresi yoktur.
5	Yönetim için kullanmayı planladığınız tüm bağdaştırıcıların yapılandırılan VLAN kimliği aynı olmalıdır.

Depolama için özel IP'ler

Varsayılan olarak, ağ ATC aşağıdaki tablodan depolama için IP'leri ve VLAN'ları otomatik olarak atar:

Depolama Bağdaştırıcısı	IP Adresi ve Alt Ağ	Sanal Yerel Alan Ağı (VLAN)
pNIC1	10.71.1.x	711
pNIC2	10.71.2.x	712
pNIC3	10.71.3.x	713

Ancak dağıtım gereksinimleriniz bu varsayılan IP'lere ve VLAN'lara uymuyorsa depolama için kendi IP'lerinizi, alt ağınızı ve VLAN'larınızı kullanabilirsiniz. Bu işlevsellik yalnızca ARM şablonlarını kullanarak kümeleri dağıtırken kullanılabilir ve şablonunuzda aşağıdaki parametreleri belirtmeniz gerekir.

• enableStorageAutoIP: Bu parametre belirtilmediğinde true olarak ayarlanır. Dağıtım sırasında özel depolama IP'lerini etkinleştirmek için bu parametre false olarak ayarlanmalıdır.
• storageAdapterIPInfo: Bu parametrenin "enableStorageAutoIP" parametresiyle bir bağımlılığı vardır ve depolama otomatik IP parametresi false olarak ayarlandığında her zaman gereklidir. ARM şablonunuzdaki "storageAdapterIPInfo" parametresinde, her düğüm ve ağ bağdaştırıcısı için kendi IP'leriniz ve alt ağ maskeniz ile "ipv4Address" ve "subnetMask" parametrelerini de belirtmeniz gerekir.
• vlanId: Yukarıda tabloda açıklandığı gibi, bu parametre değiştirmeniz gerekmiyorsa Ağ ATC varsayılan VLAN'larını kullanır. Ancak, bu varsayılan VLAN'lar ağınızda çalışmazsa, depolama ağlarınızın her biri için kendi VLAN kimliklerinizi belirtebilirsiniz.

Aşağıdaki ARM şablonu, depolama IP'lerinin özelleştirildiği bir Azure Yerel örneğinde, depolama için ağ anahtarına sahip iki düğüm içeren bir örnek sunar. Özelleştirilmiş depolama IP'lerine sahip 2 düğüm dağıtımı.

Düğüm ve küme IP ataması

Azure Yerel örneği için, makine düğümleri ve küme IP'leri için IP atamak için iki seçeneğiniz vardır.

• Hem statik hem de Dinamik Ana Bilgisayar Yapılandırma Protokolü (DHCP) protokolleri desteklenir.

• Doğru düğüm IP ataması, küme yaşam döngüsü yönetimi için önemlidir. Düğümleri Azure Arc'a kaydetmeden önce statik ve DHCP seçenekleri arasında karar verin.

• Arc Kaynak Köprüsü ve Ağ Denetleyicisi gibi altyapı VM'leri ve hizmetleri yönetim IP havuzundan statik IP'leri kullanmaya devam eder. Bu, IP'leri düğümlerinize ve küme IP'nize atamak için DHCP kullanmaya karar verseniz bile yönetim IP havuzunun hala gerekli olduğu anlamına gelir.

Aşağıdaki bölümlerde her seçeneğin etkileri açıklanmıştır.

Statik IP ataması

Statik IP'ler düğümler için kullanılıyorsa, yönetim IP havuzu, dağıtım sırasında kullanılabilir bir IP alıp bunu otomatik olarak küme IP adresi olarak atamak için kullanılır.

Yönetim IP havuzu için tanımlanan IP aralığının parçası olmayan düğümler için yönetim IP'lerini kullanmak önemlidir. Makine düğümü IP'leri, tanımlanan IP aralığının aynı alt ağı üzerinde olmalıdır.

Varsayılan ağ geçidi için ve düğümün tüm fiziksel ağ bağdaştırıcıları için yapılandırılmış DNS sunucuları için yalnızca bir yönetim IP'sini atamanızı öneririz. Bu, yönetim ağı amacı oluşturulduktan sonra IP'nin değişmemesini sağlar. Bu, Azure Arc kaydı da dahil olmak üzere, dağıtım işlemi sırasında düğümlerin giden bağlantılarını korumasına olanak tanır.

Yönlendirme sorunlarını önlemek ve giden bağlantı ve Arc kaydı için hangi IP'nin kullanılacağını belirlemek için Azure portalı, birden fazla varsayılan ağ geçidinin yapılandırılıp yapılandırılmadığı doğrulanır.

İşletim sistemi yapılandırması sırasında bir sanal anahtar ve bir yönetim sanal ağ bağdaştırıcısı oluşturulduysa, düğümün yönetim IP'si bu sanal ağ bağdaştırıcısına atanmalıdır.

DHCP IP ataması

Düğümler için IP'ler bir DHCP sunucusundan alınırsa, küme IP'si için de bir dinamik IP kullanılır. Altyapı VM'leri ve hizmetleri hala statik IP'ler gerektirir ve bu, yönetim IP havuzu adres aralığının düğümler ve küme IP'sinde kullanılan DHCP kapsamından dışlanması gerektiği anlamına gelir.

Örneğin, yönetim IP aralığı altyapı statik IP'leri için 192.168.1.20/24 ile 192.168.1.30/24 arasında tanımlanmışsa, altyapı hizmetleriyle IP çakışmalarını önlemek için 192.168.1.0/24 alt ağı için tanımlanan DHCP kapsamının yönetim IP havuzuyla eşdeğer bir dışlama olması gerekir. Ayrıca, düğüm IP'leri için DHCP rezervasyonları kullanmanızı öneririz.

Yönetim amacını oluşturduktan sonra yönetim IP'sini tanımlama işlemi, ağ amacı için seçilen ilk fiziksel ağ bağdaştırıcısının MAC adresini kullanmayı içerir. Bu MAC adresi daha sonra yönetim amacıyla oluşturulan sanal ağ bağdaştırıcısına atanır. Bu, ilk fiziksel ağ bağdaştırıcısının DHCP sunucusundan aldığı IP adresinin, sanal ağ bağdaştırıcısının yönetim IP'si olarak kullandığı IP adresiyle aynı olduğu anlamına gelir. Bu nedenle, düğüm IP'si için DHCP rezervasyonu oluşturmak önemlidir.

Bulut dağıtımı sırasında kullanılan ağ doğrulama mantığı, yapılandırmalarında varsayılan ağ geçidi olan birden çok fiziksel ağ arabirimi algılarsa başarısız olur. Ana bilgisayar IP atamalarınız için DHCP kullanmanız gerekiyorsa, yukarıda açıklandığı gibi SET (anahtar eklenmiş ekip oluşturma) sanal anahtarını ve yönetim sanal ağ bağdaştırıcısını önceden oluşturmanız gerekir, böylece yalnızca yönetim sanal ağ bağdaştırıcısı DHCP sunucusundan bir IP adresi alır.

Küme düğümü IP'sinde dikkat edilmesi gerekenler

IP adresleri için özetlenen noktalar şunlardır:

#	Dikkat edilmesi gereken noktalar
1	Düğüm IP'leri statik veya dinamik adreslerden bağımsız olarak tanımlı yönetim IP havuzu aralığının aynı alt aklarında olmalıdır.
2	Yönetim IP havuzu düğüm IP'lerini içermemelidir. Dinamik IP ataması kullanıldığında DHCP dışlamalarını kullanın.
3	Mümkün olduğunca düğümler için DHCP ayırmaları kullanın.
4	DHCP adresleri yalnızca düğüm IP'leri ve küme IP'leri için desteklenir. Altyapı hizmetleri yönetim havuzundan statik IP'ler kullanır.
5	İlk fiziksel ağ bağdaştırıcısındaki MAC adresi, yönetim ağı amacı oluşturulduktan sonra yönetim sanal ağ bağdaştırıcısına atanır.

DNS sunucusuyla ilgili dikkat edilmesi gerekenler

Active Directory tabanlı Azure Yerel dağıtımları, şirket içi etki alanını ve İnternet genel uç noktalarını çözümleyebilen bir DNS sunucusu gerektirir. Dağıtımın bir parçası olarak, düğümlerde yapılandırılan altyapı IP adresi aralığı için aynı DNS sunucularını tanımlamak gerekir. Azure Kaynak Köprüsü denetim düzlemi VM ve AKS denetim düzlemi, ad çözümlemesi için aynı DNS sunucularını kullanır. Dağıtım tamamlandıktan sonra DNS sunucuları IP'lerinin değiştirilmesi desteklenmez ve Azure Yerel platform yığınındaki adresleri güncelleştirmek mümkün olmayacaktır.

Azure Yerel için kullanılan DNS sunucularının dağıtımdan önce dış ve çalışır durumda olması gerekir. Bunları Azure Yerel sanal makineleri olarak çalıştırmak desteklenmez.

DNS sunucuları adresleri için özetlenen noktalar şunlardır:

#	Dikkat edilmesi gereken noktalar
1	Kümenin tüm düğümleri genelindeki DNS sunucuları aynı olmalıdır.
2	Altyapı IP adres aralığında kullanılan DNS sunucuları, düğümler için kullanılanlarla aynı olmalıdır.
3	Azure Kaynak Köprüsü VM denetim düzlemi ve AKS denetim düzlemi, altyapı IP adresi aralığında yapılandırılan DNS Sunucularını kullanır.
4	Dağıtımdan sonra DNS sunucularının değiştirilmesi desteklenmez. Azure Yerel dağıtımını yapmadan önce DNS stratejinizi planladığınızdan emin olun.
5	Altyapı ağı için ARM şablonunda birden çok DNS sunucusu dizisi tanımlarken, aşağıdaki örnekte olduğu gibi her değerin tırnak içinde "" ve virgülle ayrıldığından emin olun.
6	Azure Yerel örneği içinde çalışan sanal makinelerde Azure Yerel altyapısı tarafından kullanılan DNS sunucularının çalıştırılması desteklenmez.
7	Yapılandırılan tüm DNS sunucularının altyapı için gerekli olan şirket içi etki alan adlarını çözmesi gerekir. 8.8.8.8 gibi genel DNS Sunucuları desteklenmez.
8	Yapılandırılan tüm DNS sunucuları ayrılmış ARB alt ağ aralıklarıyla çakışmamalıdır (10.96.0.0/12 ve 10.244.0.0/16)

"dnsServers": [
                        "10.250.16.124",
                        "10.250.17.232",
                        "10.250.18.107"
                    ]

Ara sunucu gereksinimleri

Şirket içi altyapınızda İnternet'e erişmek için büyük olasılıkla bir ara sunucu gereklidir. Azure Local yalnızca kimliği doğrulanmamış ara sunucu yapılandırmalarını destekler. Düğümleri Azure Arc'a kaydetmek için İnternet erişimi gerektiğinden, makine düğümleri kaydedilmeden önce proxy yapılandırması işletim sistemi yapılandırmasının bir parçası olarak ayarlanmalıdır. Daha fazla bilgi için Ara sunucu ayarlarını yapılandırma bölümüne bakın.

Azure Stack HCI işletim sistemi, tüm işletim sistemi bileşenlerinin İnternet'e erişebildiğinden emin olmak için aynı ara sunucu yapılandırması gerektiren üç farklı hizmete (WinInet, WinHTTP ve ortam değişkenleri) sahiptir. Düğümler için kullanılan proxy yapılandırması, dağıtım sırasında Arc Kaynak Köprüsü VM'sine ve AKS'ye otomatik olarak aktarılır ve bu süreçte İnternet erişimine sahip olmalarını garanti eder.

Ara sunucu yapılandırmasıyla ilgili özetlenmiş noktalar şunlardır:

#	Dikkat edilmesi gereken noktalar
1	Düğümleri Azure Arc'a kaydetmeden önce ara sunucu ayarlarının tamamlanması gerekir.
2	WinINET, WinHTTP ve ortam değişkenleri için aynı ara sunucu yapılandırması uygulanmalıdır.
3	Ortam Denetleyicisi, ara sunucu yapılandırmasının tüm ara sunucu bileşenlerinde tutarlı olmasını sağlar.
4	Arc Resource Bridge VM ve AKS'nin ara sunucu yapılandırması dağıtım sırasında düzenleyici tarafından otomatik olarak gerçekleştirilir.
5	Yalnızca kimliği doğrulanmamış proxy'ler desteklenir.
8	Azure Yerel düğümleri için yapılandırılan ara sunucu ayrılmış ARB alt ağ aralıklarıyla çakışmamalıdır (10.96.0.0/12 ve 10.244.0.0/16)

Güvenlik duvarı gereksinimleri

Azure Yerel'in ve bileşenlerinin bunlara başarıyla bağlanabilmesini sağlamak için şu anda güvenlik duvarlarınızda birkaç internet uç noktası açmanız gerekir. Gerekli uç noktaların ayrıntılı listesi için bkz . Güvenlik duvarı gereksinimleri.

Güvenlik duvarı yapılandırması, düğümleri Azure Arc'a kaydetmeden önce yapılmalıdır. Güvenlik duvarlarınızın bu uç noktalara gönderilen trafiği engellemediğini doğrulamak için ortam denetleyicisinin tek başına sürümünü kullanabilirsiniz. Daha fazla bilgi için bkz. Azure Local için dağıtım hazırlığını değerlendirmek için bkz . Azure Yerel Ortam Denetleyicisi .

Güvenlik duvarıyla ilgili özetlenen noktalar şunlardır:

#	Dikkat edilmesi gereken noktalar
1	Azure Arc'a düğümleri kaydetmeden önce güvenlik duvarı yapılandırması gerçekleştirilmelidir.
2	Tek başına modda Ortam Denetleyicisi, güvenlik duvarı yapılandırmasını doğrulamak için kullanılabilir.

5. Adım: Ağ bağdaştırıcısı yapılandırmasını belirleme

Ağ bağdaştırıcıları, birlikte kullanıldıkları ağ trafiği türüne (yönetim, işlem ve depolama) göre nitelenir. Windows Server Kataloğu'nu gözden geçirirken, Windows Server 2022 sertifikası bağdaştırıcıların hangi ağ trafiği için uygun olduğunu gösterir.

Azure Yerel için bir makine satın almadan önce, Azure Yerel'de üç trafik türünün de gerekli olması için yönetim, işlem ve depolama için uygun olan en az bir bağdaştırıcınız olmalıdır. Bulut dağıtımı, ağ bağdaştırıcılarını uygun trafik türleri için yapılandırmak için Ağ ATC'sini kullanır, bu nedenle desteklenen ağ bağdaştırıcılarını kullanmak önemlidir.

Ağ ATC tarafından kullanılan varsayılan değerler Küme ağ ayarları bölümünde belgelenmiştir. Varsayılan değerleri kullanmanızı öneririz. Bununla birlikte, gerekirse Azure portalı veya Resource Manager şablonları kullanılarak aşağıdaki seçenekler geçersiz kılınabilir:

• Depolama VLAN'ları: Bu değeri depolama için gerekli VLAN'lara ayarlayın.
• Jumbo Paketleri: Jumbo paketlerinin boyutunu tanımlar.
• Ağ Doğrudan: Ağ bağdaştırıcılarınız için RDMA'yı devre dışı bırakmak istiyorsanız bu değeri false olarak ayarlayın.
• Doğrudan Ağ Teknolojisi: Bu değeri RoCEv2 veya iWarp olarak ayarlayın.
• Trafik Öncelikleri Veri Merkezi Köprü Oluşturma (DCB): Gereksinimlerinize uygun öncelikleri ayarlayın. Bunlar Microsoft ve müşteriler tarafından doğrulandığından varsayılan DCB değerlerini kullanmanızı kesinlikle öneririz.

Ağ bağdaştırıcısı yapılandırmasıyla ilgili özetlenen noktalar şunlardır:

#	Dikkat edilmesi gereken noktalar
1	Varsayılan yapılandırmaları mümkün olduğunca kullanın.
2	Fiziksel anahtarlar, ağ bağdaştırıcısının yapılandırmasına uygun şekilde ayarlanmalıdır. Bkz. Azure Yerel için fiziksel ağ gereksinimleri.
3	Windows Server Kataloğu'nu kullanarak ağ bağdaştırıcılarınızın Azure Yerel için desteklendiğinden emin olun.
4	Ağ ATC, varsayılanları kabul ederken depolama ağ bağdaştırıcısı IP'lerini ve VLAN'larını otomatik olarak yapılandırıyor. Bu, Depolama Otomatik IP yapılandırması olarak bilinir. Bazı durumlarda, Depolama Otomatik IP'si desteklenmez ve Resource Manager şablonlarını kullanarak her depolama ağ bağdaştırıcısı IP'sini bildirmeniz gerekir.

Sonraki adımlar

• Azure Yerel Dağıtım Hakkında.