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 az kaynak gerekir ve üretime geçerken daha fazla kaynağa ihtiyaç duyarsınız ve uygulamanız popülerliğini geliştirir. Uygulamanızı tasarlarken, uzun vadeli gereksinimleri düşünün 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çmek 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 bulundurmalısınız. Hizmetinizin hizmet kullanımı arttıkça iyi performans göstermesi gerekiyorsa, kümeye daha fazla VM ekleyebilir ve tüm VM'lerde ağ isteklerinin yük dengelemesini yapabilirsiniz.
VM'lerde 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 dikkatle 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'de istediğiniz verileri depolayabilecek kadar büyük bir disk 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 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 gb DB_Size büyütmeyi beklediğiniz bir mağaza boyutuna sahip tek bir durum bilgisi olan hizmete sahip olduğunu varsayalım. Bu yıldan sonra büyüme yaşarken daha fazla uygulama (ve bölüm) eklemek istiyorsunuz. Hizmetiniz için ç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 sayfa içinde/dışındadı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ı
Hizmetinizin artmasını beklediğiniz DB_Size temel alarak, başladığınız DB_Size bağlı olarak düğüm sayısını hesaplamak isteyebilirsiniz. Ardından hizmetiniz büyüdükçe düğüm sayısını büyütüp düğüm sayısını fazla sağlamayabilirsiniz. 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 ek makinelerin kullanılabilir olması iyidir. Ek kapasitenin beklenen ani artışlar kullanılarak belirlenmesi gerekirken, başlangıç noktası birkaç ek VM ayırmaktır (fazladan yüzde 5-10).
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. Üç tür veri nesnesi içeren bir uygulama için kapasitenin nasıl planlandığını gösteren örnek bir elektronik tablo . Her nesne için boyutuna ve sahip olmasını beklediğimiz nesne sayısını tahmin ediyoruz. Ayrıca her nesne türünden 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 arttığını gösterir.
Şimdi, tüm bu bilgilere dayanarak, elektronik tablo istenen bölümleri ve çoğaltmaları içeren tüm verileri 26 düğümlü bir kümede fiziksel olarak alabildiğinizi gösteriyor. Ancak, bu küme yoğun bir şekilde paketlenir, bu nedenle düğüm hatalarına ve yükseltmelerine uyum sağlamak için bazı ek düğümler 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ına ve yükseltmelerine uyum sağlamak için yine de 57 düğümün üzerine çıkmak isteyebilirsiniz. Elektronik tabloyu, uygulamanızın özel gereksinimlerine uyacak şekilde ayarlayabilirsiniz.
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.