Geçiş öncesinde iş yükü mimarisi tasarlama

Bu makalede, buluttaki bir iş yükünün hedeflenen geçirilen durumunu tasarlama işlemi ve dikkat edilmesi gerekenler açıklanmaktadır. Makale, bir yineleme içinde iş yükünün mimarisini tanımlamanın bir parçası olan etkinlikleri inceler.

Artımlı rasyonalizasyon hakkındaki makale, bazı mimari varsayımların geçiş içeren tüm iş dönüşümlerinin bir parçası olduğunu gösterir. Bu makalede tipik varsayımlar açıklanır. Ayrıca kaçınabileceğiniz birkaç engele işaret eder ve mimari varsayımları zorlayarak iş değerini hızlandırma fırsatlarını belirler. Mimari tasarlamaya yönelik bu artımlı model, ekiplerin daha hızlı ilerlemelerine ve iş sonuçlarını daha erken elde etmelerine yardımcı olur.

Yaygın varsayımlara dayalı temel mimari tasarımı

Aşağıdaki varsayımlar, herhangi bir geçiş eforu için tipik olarak verilmiştir:

• Hizmet olarak altyapı (IaaS) iş yükü varsayma. İş yüklerinin geçirilmesi öncelikli olarak sunucuları fiziksel bir veri merkezinden IaaS geçişi yoluyla bulut veri merkezine taşımayı içerir. İşlem genellikle en az yeniden geliştirme veya yeniden yapılandırma gerektirir. Bu yaklaşım, lift and shift geçişi olarak bilinir.
• Mimarinin tutarlı kalmasını sağlayın. Geçiş sırasında çekirdek mimaride değişiklik yapmak karmaşıklığı önemli ölçüde artırır. Yeni bir platformda değiştirilen bir sistemin hatalarının ayıklanması, yalıtılması zor olabilecek birçok değişkeni getirir. İş yükleri geçiş sırasında yalnızca küçük değişikliklerden geçirilmelidir ve tüm değişiklikler kapsamlı bir şekilde test edilmelidir.
• Varlıkları yeniden boyutlandırmayı planlayın. Birkaç şirket içi varlığın herhangi bir kaynağı tam olarak kullandığını varsayalım. Geçiş öncesinde veya sırasında varlıklar gerçek kullanım gereksinimlerine en uygun şekilde yeniden boyutlandırılır. Azure Geçişi ve Modernleştirme gibi araçlar, gerçek kullanıma göre boyutlandırma sağlar.
• İş sürekliliği ve olağanüstü durum kurtarma (BCDR) gereksinimlerini yakalayın. İş yükü için zaten üzerinde anlaşmaya varılmış bir hizmet düzeyi sözleşmeniz (SLA) varsa, Azure'a geçiş sonrasında SLA'yı kullanmaya devam edin. SLA henüz ayarlanmadıysa, uygun şekilde tasarladığınızdan emin olmak için iş yükünü bulutta tasarlamadan önce bir SLA tanımlayın.
• Geçiş kapalı kalma süresini planlayın. SLA gereksinimlerini karşılayamaması gibi, bir iş yükünü üretime yükselttiğiniz zaman oluşan kapalı kalma süresi de işletmeyi olumsuz yönde etkileyebilir. Bazen en düşük kapalı kalma süresiyle geçiş yapması gereken çözümler mimari değişikliklerine ihtiyaç duyar. Sürüm planlamasına başlamadan önce, kapalı kalma süresi gereksinimlerini genel olarak anladığınız varsayın.
• Kullanıcı ve uygulama trafiği desenlerini tanımlayın. Mevcut çözümler mevcut ağ yönlendirme desenlerine ve çözümlerine bağlı olabilir. Geçerli ağ kullanımını desteklemek için ihtiyacınız olan kaynakları belirleyin.
• Ağ çakışmalarını önlemeyi planlayın. Veri merkezlerini tek bir bulut sağlayıcısında birleştirdiğinizde, Etki Alanı Adı Sistemi'nde (DNS) veya diğer ağ yapılarında çakışmalar oluşturabilirsiniz. Geçiş sırasında, bulutta barındırılan üretim sistemlerinde kesinti yaşanmasını önlemek için bu çakışmaları önlemek için tasarım yapmak önemlidir.
• Yönlendirme tablolarını planlayın. Ağları veya veri merkezlerini birleştirirseniz, projenizde yönlendirme tablolarını değiştirmeye yönelik bir plan bulunduğuna emin olun. Çapraz veri merkezi yönlendirme gereksinimlerini göz önünde bulundurun.

Giriş bölgesi için tasarım mimarisi

kuruluşunuz, Bulut Benimseme Çerçevesi Hazır aşamasında Azure giriş bölgelerini benimsemenin bir parçası olarak paylaşılan platform hizmetlerini dağıttı. Giriş bölgenizi geçiş için hazırlayın bölümünde, geçirilen iş yüklerini almak için giriş bölgesini hazırladınız.

Bu planlamaya bağlı olarak, aşağıdaki geçiş bileşenlerinin yerinde olduğunu varsayabilirsiniz:

• Karma bağlantı, Azure ağlarınızı şirket içi ağlarınıza bağlar.
• Azure Güvenlik Duvarı gibi ağ güvenlik gereçleri, iş yükünüzün dışındaki trafiği denetlemeyi işler.
• Günlük gereksinimleri, izin verilen bölgeler, izin verilmeyen hizmetler ve diğer denetimler gibi idare uygulamalarını uygulamaya yönelik Azure ilkeleri etkindir.
• Paylaşılan günlük kaydı için Azure İzleyici Günlükleri çalışma alanı, Azure İzleyici'de ayarlanır.
• Etki alanına katılmış sunucuları veya diğer kimlik gereksinimlerini desteklemek için paylaşılan kimlik kaynakları oluşturulur.

Bu geçişle ilgili temel bilgiler oluşturulmamışsa, kuruluşunuzun bu gereksinimleri karşılamak için Hazır aşamasını hemen yeniden ziyaret etmesi gerekir. Bu bileşenler olmadan, geçişinizde büyük olasılıkla gecikmeler ve geri dönüşler olur ve daha az başarılı olur.

Tasarladığınız iş yüküne, ideal olarak bir abonelik aracı işlemi aracılığıyla atanmış bir abonelik vardır. Abonelik, kuruluşunuzun iş yükleri için kaynak kuruluşunu nasıl tamamlandığına bağlı olarak birkaç iş yükü veya yalnızca bir iş yükü içerebilir. Çok sayıda uygulama ortamına sahip bir iş yükünü geçirirseniz, uygulama ortamları kılavuzuna bağlı olarak birden çok aboneliğiniz bile olabilir.

İş yükü ağ mimarisi tasarlama

Uygulamaya özgü kaynakları belirli bir aboneliğe dağıtmayı ve iş yükü için ayrılmış bir sanal ağ tasarlamayı planlayın. Daha fazla bilgi için bkz. Ağ mimarinizi tasarlama yönergeleri. Özellikle sanal ağları segmentlere ayırmaya odaklanmalısınız.

Ağınız büyük olasılıkla yük dengeleyiciler ve diğer uygulama teslim kaynakları gibi kaynaklara ihtiyaç duyar. Bu kaynakları Azure'da planlamak için N katmanlı mimari kılavuzunu kullanabilirsiniz.

İş yükü bağımlılıklarını tasarlama

Geçiş değerlendirme araçlarınız, Azure Geçişi ve Modernleştirme'de bağımlılık analizi gibi bağımlılık analizi yapmanız için size bir yol sunmalıdır. Araç, sunucular arasındaki bağımlılıkları belirlemenize yardımcı olur.

İş yükünün mimarisini planlamaya ek olarak, iş yükünden iş yüküne bağımlılıkları da göz önünde bulundurmanız gerekebilir. Örneğin, bazı iş yüklerinin sık iletişim kurması gerekebilir. Öyleyse, geçiş dalgalarınızı ve bağımlılıklarınızı bu gereksinimi dikkate almak üzere planlamak, geçişinizin başarılı olmasını sağlar.

Geçiş sonrasında birbirine bağlı iş yüklerinin nasıl çalışabileceğini tasarlamak için Azure Mimari Merkezi'nde, örneğin uçlar arası ağ oluşturma yönergelerini kullanabilirsiniz.

Gizli bilgi işlem benimsemeye hazırlanma

Egemenlik gereksinimleri olan iş yüklerinizin bir alt kümesi, gizli bilgi işlemin kullanılmasına neden olabilir. Bağımsız giriş bölgesi dağıtımının bir parçası olarak, gizli bilgi işlem için yönetim grupları oluşturulur.

Bir egemenlik bağlamında, gizli bilgi işlemin kullanılması için Azure Key Vault ve destek hizmeti olarak müşteri tarafından yönetilen anahtarlar gerekir. Daha fazla bilgi için bkz . Bağımsızlık için Microsoft Bulut'ta müşteri tarafından yönetilen anahtarlarla şifreleme.

İlk bulut tahmininizi güncelleştirme

Mimari tasarımınızı tamamladığınızda, planlı bütçenin içinde olduğunuzdan emin olmak için bulut tahmininizi yeniden ziyaret edin. Yük dengeleyiciler veya yedeklemeler gibi destekleyici hizmetler ekledikçe maliyetler değişebilir. Ayrıntılı maliyet yönetimi alıştırmaları yapmak için Azure Geçişi ve Modernleştirme'deki iş durumları gibi araçları kullanabilirsiniz ancak mimari tasarımınızı ayarlarken tahminlerinizi düzenli aralıklarla yeniden ziyaret etmelisiniz.

Geleneksel BT tedarik süreçlerini biliyorsanız, buluttaki kaynakları tahmin etmek yabancı görünebilir. Bulut teknolojilerini benimsediğinizde alım, katı, yapılandırılmış bir sermaye gider modelinden akışkan işletim gider modeline geçer. Buluta geçişi planlamak genellikle bir kuruluşun veya BT ekibinin bu değişiklikle ilk karşılaşmasıdır.

Geleneksel sermaye gider modelinde, BT ekibi çeşitli programlarda birden çok iş yükü için satın alma gücünü birleştirmeye çalışır. Bu yaklaşım, bu çözümlerin her birini destekleyebilecek paylaşılan BT varlıklarının havuzunu merkezileştirir. İşletme giderleri bulut modelinde maliyetler, tek tek iş yüklerinin, ekiplerin veya iş birimlerinin destek gereksinimlerine doğrudan bağlanabilir. Bir kuruluşa maliyetlerin şirket içindeki müşterilere ve destekledikleri iş hedeflerine daha doğrudan bir şekilde atfını verir. Finansal yönetime yönelik bu daha dinamik yaklaşım genellikle finansal operasyonlar (FinOps) olarak adlandırılır. FinOps, Azure'a özgü bir konu olmasa da, FinOps hakkında daha fazla bilgi sahibi olmak yararlı olabilir. Daha fazla bilgi için bkz . FinOps nedir?.

geçiş için iş yükü mimarinizi tasarlarken, iş yükünün tamamının fiyatını anlamak için değerlendirme bilgilerinizle birlikte fiyatlandırma hesaplayıcısını kullanabilirsiniz.

Ayrıca, iş yükünüz geçirildikten sonra iş yükü maliyetlerini iyileştirmek için çalışmaya devam etmelisiniz. Kuruluşların maliyet yönetimi becerilerini nasıl geliştirebilecekleri hakkında daha fazla bilgi için bkz . Maliyet yönetimi uzmanlık alanlarını geliştirme.

Mimarinizi ne zaman değiştireceğini öğrenme

Geçişler, mevcut bir mimariyi korumaya ve bunu bulut platformunuza geçirmeye odaklanma eğilimindedir. Ancak, geçiş için bile iş yükünüzü yeniden oluşturmanız gerekebilecek zamanlar olabilir. Bu liste, geçirmeden önce mimari değişiklikler yapmanız gerekebilecek örnekler verir:

• Teknik borç için ödeme yapma. Bazı eskiyen iş yükleri yüksek miktarda teknik borç taşır. Teknik borç, herhangi bir bulut sağlayıcısıyla barındırma maliyetlerini artırarak uzun vadeli zorluklara yol açabilir. Teknik borç, barındırma maliyetlerini doğal olarak artırdığında, alternatif mimarileri değerlendirmeniz gerekir.
• Güvenilirliği artırma. Standart işlem temelleri, bulutta bir derece güvenilirlik ve kurtarma sağlar. Bazı iş yükü ekipleri daha yüksek SLA'lara ihtiyaç duyabilir ve bu da mimari değişikliklere yol açabilir.
• Yüksek maliyetli iş yükleri. Geçiş sırasında, boyutlandırmayı gerçek kullanımla uyumlu hale getirmek için tüm varlıkları iyileştirmeniz gerekir. Bazı iş yükleri, belirli maliyet sorunlarını gidermek için mimari değişiklikler gerektirebilir.
• Performans gereksinimleri. İş yükü performansı işi doğrudan etkilediyse, ek mimari değerlendirme gerekebilir.
• Güvenli uygulamalar. Güvenlik gereksinimleri merkezi olarak uygulanma eğilimindedir ve genellikle portföydeki tüm iş yüklerine uygulanır. Bazı iş yüklerinin mimari değişikliklere yol açabilecek belirli güvenlik gereksinimleri olabilir.

Bu ölçütlerin her biri, olası bir geçiş engelinin göstergesi olarak işlev görür. Çoğu durumda, sunucuları doğru boyutlandırarak, yeni sunucular ekleyerek veya başka değişiklikler yaparak iş yükünü geçirdikten sonra ölçütü ele alabilirsiniz. Ancak, bir iş yükünü geçirmeden önce bu ölçütlerden herhangi biri gerekiyorsa, iş yükünü geçiş dalgasından kaldırın ve tek tek değerlendirin.

Azure İyi Tasarlanmış Çerçeve ve Azure İyi Tasarlanmış Gözden Geçirme, belirli bir iş yükünün teknik sahibiyle yapılan konuşmalara yol göstermesine yardımcı olarak iş yükünü dağıtmaya yönelik alternatif seçenekleri düşünmelerine yardımcı olabilir.

Daha sonra iş yükü, bulut benimseme planınızda bir yeniden oluşturma veya modernleştirme çalışması olarak sınıflandırılır. Bir iş yükünü yeniden oluşturmak için gereken ek süre nedeniyle, bu alternatif iş yükü benimseme yollarını geçiş işleminden ayrı olarak düşünün.

Mimari denetim listesi

Önemli mimari konuları ele almak için aşağıdaki denetim listesini kullanabilirsiniz:

• Mimarinizin kullanılabilirlik, olağanüstü durum kurtarma ve veri kurtarma için SLA'ları karşıladığını onaylayın.
• Ağ tasarımınıza ağ kesimleme uygulamaları uyguladığınızı onaylayın.
• İzleme ve günlük yakalamayı planladığınızı onaylayın.
• Sanal makinelerinizin ihtiyacınız olan gerçek bilgi işlem süresi için uygun şekilde boyutlandırıldığını onaylayın.
• Disklerinizin ihtiyacınız olan gerçek boyut ve performans için uygun şekilde boyutlandırıldığını onaylayın.
• Gerekirse yük dengeleme hizmetlerini planladığınızı onaylayın. Hizmetler Azure Load Balancer, Azure Uygulaması lication Gateway, Azure Front Door veya Azure Traffic Manager örneklerini içerebilir.
• Gerekirse, egemenlik ve gizli bilgi işlem gereksinimlerini planladığınızı onaylayın.

Sonraki adım