Aracılığıyla paylaş


Service Fabric uygulamaları için kapasite planlaması

Bu belgede, Azure Service Fabric uygulamalarınızı çalıştırmak için ihtiyacınız olan kaynak miktarını (CPU'lar, RAM, disk depolama) nasıl tahmin etmeniz gerektiği öğretildi. Kaynak gereksinimlerinizin zaman içinde değişmesi yaygın bir durumdur. Hizmetinizi geliştirirken/test ederken genellikle birkaç kaynağa ihtiyacınız olur ve üretime geçerken daha fazla kaynağa ihtiyacınız olur ve uygulamanız popülerliği artar. Uygulamanızı tasarlarken, uzun vadeli gereksinimleri göz ardı edin ve hizmetinizin yüksek müşteri talebini karşılayacak şekilde ölçeklendirilmesini sağlayan seçimler yapın.

Service Fabric kümesi oluşturduğunuzda, kümeyi ne tür sanal makinelerin (VM) oluşturduğuna karar verirsiniz. Her VM CPU (çekirdek ve hız), ağ bant genişliği, RAM ve disk depolama biçiminde sınırlı miktarda kaynakla birlikte gelir. Hizmetiniz zamanla büyüdükçe daha fazla kaynak sunan VM'lere yükseltebilir ve/veya kümenize daha fazla VM ekleyebilirsiniz. İkincisini yapmak için, kümeye dinamik olarak eklenen yeni VM'lerden yararlanabilmesi için başlangıçta hizmetinizin mimarisini oluşturmanız gerekir.

Bazı hizmetler VM'lerin kendilerinde çok az veya hiç veri yönetmez. Bu nedenle, bu hizmetler için kapasite planlaması öncelikli olarak performansa odaklanmalıdır; bu da VM'lerin uygun CPU'larını (çekirdekler ve hız) seçme anlamına gelir. Ayrıca, ağ aktarımlarının ne sıklıkta gerçekleştiği ve ne kadar veri aktarıldığı da dahil olmak üzere ağ bant genişliğini göz önünde bulundurmanız gerekir. Hizmet kullanımı arttıkça hizmetinizin iyi performans göstermesi gerekiyorsa, kümeye daha fazla VM ekleyebilir ve tüm VM'lerde ağ isteklerinin yük dengelemesini yapabilirsiniz.

VM'lerdeki büyük miktarda veriyi yöneten hizmetler için kapasite planlaması öncelikli olarak boyuta odaklanmalıdır. Bu nedenle, VM'nin RAM ve disk depolama kapasitesini dikkatli bir şekilde dikkate almanız gerekir. Windows'daki sanal bellek yönetim sistemi, disk alanının uygulama koduna RAM gibi görünmesini sağlar. Buna ek olarak, Service Fabric çalışma zamanı akıllı disk belleği sağlayarak yalnızca etkin verileri bellekte tutar ve soğuk verileri diske taşır. Bu nedenle uygulamalar VM'de fiziksel olarak kullanılabilir olandan daha fazla bellek kullanabilir. VM RAM'de daha fazla disk depolama alanı tutabildiğinden, daha fazla RAM'e sahip olmak performansı artırır. Seçtiğiniz VM'nin, vm'de istediğiniz verileri depolayabilecek kadar büyük bir diski olmalıdır. Benzer şekilde, VM'nin size istediğiniz performansı sağlamak için yeterli RAM'i olmalıdır. Hizmetinizin verileri zaman içinde büyürse kümeye daha fazla VM ekleyebilir ve verileri tüm VM'ler arasında bölümleyebilirsiniz.

Kaç düğüme ihtiyacınız olduğunu belirleme

Hizmetinizi bölümlemek, hizmetinizin verilerinin ölçeğini genişletmenize olanak tanır. Bölümleme hakkında daha fazla bilgi için bkz . Service Fabric'i Bölümleme. Her bölüm tek bir VM'ye sığmalıdır, ancak tek bir VM'ye birden çok (küçük) bölüm yerleştirilebilir. Bu nedenle, daha fazla küçük bölüme sahip olmak, birkaç daha büyük bölüme sahip olmaktan daha fazla esneklik sağlar. Bunun dezavantajı, çok sayıda bölüme sahip olmanın Service Fabric ek yükünü artırması ve bölümler arasında işlem yapılan işlemleri gerçekleştirememenizdir. Hizmet kodunuzun sık sık farklı bölümlerde bulunan veri parçalarına erişmesi gerekiyorsa daha fazla olası ağ trafiği de vardır. Hizmetinizi tasarlarken, etkili bir bölümleme stratejisine ulaşmak için bu artıları ve dezavantajları dikkatle dikkate almanız gerekir.

Uygulamanızın, bir yıl içinde DB_Size GB'a kadar büyütmeyi beklediğiniz mağaza boyutuna sahip tek bir durum bilgisi olan hizmete sahip olduğunu varsayalım. Bu yılın ötesinde bir büyüme yaşarken daha fazla uygulama (ve bölüm) eklemeye isteklisiniz. Hizmetinizin çoğaltma sayısını belirleyen çoğaltma faktörü (RF), toplam DB_Size etkiler. Tüm çoğaltmalardaki toplam DB_Size Çoğaltma Faktörü'ne DB_Size çarpılır. Node_Size hizmetiniz için kullanmak istediğiniz düğüm başına disk alanını/RAM'i temsil eder. En iyi performans için DB_Size küme genelinde belleğe sığmalıdır ve VM'nin RAM'inin etrafındaki bir Node_Size seçilmelidir. RAM kapasitesinden daha büyük bir Node_Size ayırarak, Service Fabric çalışma zamanı tarafından sağlanan disk belleğini kullanırsınız. Bu nedenle, verilerinizin tamamı sık erişimli olarak kabul edilirse performansınız en uygun olmayabilir (o zamandan beri veriler giriş/çıkış sayfalanır). Ancak, verilerin yalnızca bir kısmının sık erişimli olduğu birçok hizmet için daha uygun maliyetlidir.

En yüksek performans için gereken düğüm sayısı aşağıdaki gibi hesaplanabilir:

Number of Nodes = (DB_Size * RF)/Node_Size

Büyüme hesabı

Kullanmaya başladığınız DB_Size ek olarak hizmetinizin artmasını beklediğiniz DB_Size göre düğüm sayısını hesaplamak isteyebilirsiniz. Ardından, hizmetiniz büyüdükçe düğüm sayısını büyütün, böylece düğüm sayısını fazla sağlamazsınız. Ancak bölüm sayısı, hizmetinizi en yüksek büyümede çalıştırırken gereken düğüm sayısına bağlı olmalıdır.

Beklenmeyen ani artışları veya hataları (örneğin, birkaç VM'nin kapanması gibi) kaldırabilmeniz için herhangi bir zamanda bazı ek makinelerin kullanılabilir olması iyidir. Ek kapasitenin beklenen ani artışlar kullanılarak belirlenmesi gerekirken, başlangıç noktası birkaç ek VM (yüzde 5-10 ek) ayırmaktır.

Yukarıdaki, durum bilgisi olan tek bir hizmet olduğunu varsayar. Birden fazla durum bilgisi olan hizmetiniz varsa, denkleme diğer hizmetlerle ilişkili DB_Size eklemeniz gerekir. Alternatif olarak, durum bilgisi olan her hizmet için düğüm sayısını ayrı ayrı hesaplayabilirsiniz. Hizmetinizde dengeli olmayan çoğaltmalar veya bölümler olabilir. Bölümlerin diğerlerinden daha fazla veriye sahip olabileceğini unutmayın. Bölümleme hakkında daha fazla bilgi için en iyi yöntemlerle ilgili bölümleme makalesine bakın. Ancak, Service Fabric çoğaltmaların düğümler arasında iyileştirilmiş bir şekilde yayılmasını sağladığından, yukarıdaki denklem bölümleme ve çoğaltmadan bağımsızdır.

Maliyet hesaplaması için elektronik tablo kullanma

Şimdi formüle bazı gerçek sayılar ekleyelim. Örnek bir elektronik tablo , üç tür veri nesnesi içeren bir uygulamanın kapasitesinin nasıl planlandığını gösterir. Her nesne için boyutuna ve sahip olmasını beklediğimiz nesne sayısını tahmin ediyoruz. Ayrıca her nesne türü için kaç çoğaltma istediğimizi de seçiyoruz. Elektronik tablo, kümede depolanacak toplam bellek miktarını hesaplar.

Ardından bir VM boyutu ve aylık maliyet gireriz. Elektronik tablo, VM boyutuna bağlı olarak verilerinizi düğümlere fiziksel olarak sığacak şekilde bölmek için kullanmanız gereken en az bölüm sayısını bildirir. Uygulamanızın belirli hesaplama ve ağ trafiği gereksinimlerini karşılamak için daha fazla sayıda bölüm isteyebilirsiniz. Elektronik tablo, kullanıcı profili nesnelerini yöneten bölümlerin sayısının birden altıya yükseldiğini gösterir.

Şimdi, tüm bu bilgilere dayanarak, elektronik tablo istenen bölümlere ve çoğaltmalara sahip tüm verileri 26 düğümlü bir kümede fiziksel olarak alabileceğinizi gösteriyor. Ancak, bu küme yoğun bir şekilde paketlenir, bu nedenle bazı ek düğümlerin düğüm hatalarına ve yükseltmelerine uyum sağlamasını isteyebilirsiniz. Elektronik tablo ayrıca 57'den fazla düğüme sahip olmanın, boş düğümleriniz olacağından ek değer sağlamadığını da gösterir. Yine, düğüm hatalarını ve yükseltmelerini karşılamak için 57 düğümün üzerine çıkmak isteyebilirsiniz. Elektronik tabloyu, uygulamanızın özel gereksinimlerine uyacak şekilde ayarlayabilirsiniz.

Maliyet hesaplama için elektronik tablo

Sonraki adımlar

Hizmetinizi bölümleme hakkında daha fazla bilgi edinmek için Service Fabric hizmetlerini bölümleme bölümüne bakın.