Giriş
Kullanıcı açısından bir bilgi sistemi GOST RV 51987'de iyi tanımlanmıştır - "sonucu, daha sonra kullanılmak üzere çıktı bilgilerinin sunulması olan otomatik bir sistem." İç yapıyı düşünürsek, özünde herhangi bir IS, kodda uygulanan birbirine bağlı algoritmalardan oluşan bir sistemdir. Turing-Church tezinin geniş anlamıyla, bir algoritma (veya IS), bir dizi girdi verisini bir dizi çıktı verisine dönüştürür.
Hatta girdi verilerinin dönüştürülmesinin bir bilgi sisteminin varlığının anlamı olduğu bile söylenebilir. Buna göre IS'nin ve tüm IS kompleksinin değeri, girdi ve çıktı verilerinin değeri aracılığıyla belirlenir.
Buna dayanarak tasarım başlamalı ve veri odaklı olmalı, mimariyi ve yöntemleri verilerin yapısına ve önemine göre uyarlamalıdır.
Depolanmış veri
Tasarıma hazırlanmanın önemli bir aşaması, işlenmesi ve saklanması planlanan tüm veri setlerinin özelliklerinin elde edilmesidir. Bu özellikler şunları içerir:
- Veri hacmi;
— Verilerin yaşam döngüsüne ilişkin bilgiler (yeni verilerin büyümesi, kullanım ömrü, güncel olmayan verilerin işlenmesi);
— Verilerin bakış açısına göre sınıflandırılması Şirketin ana faaliyet alanı (gizlilik, bütünlük, kullanılabilirlik üçlüsü) ile finansal göstergeler (örneğin, son bir saatteki veri kaybının maliyeti) üzerindeki etki;
— Veri işleme coğrafyası (işleme sistemlerinin fiziksel konumu);
— Her veri sınıfı için düzenleyici gereklilikler (örneğin, Federal Kanun-152, PCI DSS).
Bilgi sistemleri
Veriler bilgi sistemleri tarafından yalnızca saklanmaz, aynı zamanda işlenir (dönüştürülür). Veri özelliklerinin elde edilmesinden sonraki bir sonraki adım, dört tür kaynak için geleneksel birimlerdeki bilgi sistemlerinin, bunların mimari özelliklerinin, karşılıklı bağımlılıklarının ve altyapı gereksinimlerinin en eksiksiz envanterinin çıkarılmasıdır:
— İşlemci bilgi işlem gücü;
- RAM miktarı;
— Veri depolama sisteminin hacmi ve performansına ilişkin gereksinimler;
— Veri iletim ağı gereksinimleri (harici kanallar, IS bileşenleri arasındaki kanallar).
Bu durumda IS'nin parçası olarak her hizmet/mikro hizmet için gereksinimler bulunmalıdır.
Ayrı olarak, doğru tasarım için, IS'nin şirketin ana işi üzerindeki etkisine ilişkin verilerin IS kesinti süresi maliyeti (saat başına ruble) şeklinde bulunmasının zorunlu olduğunu belirtmek gerekir.
Tehdit modeli
Verilerin/hizmetlerin korunmasının planlandığı resmi bir tehdit modeli bulunmalıdır. Üstelik tehdit modeli yalnızca gizliliği değil aynı zamanda bütünlük ve kullanılabilirliği de içeriyor. Onlar. Örneğin:
— Fiziksel sunucunun arızası;
— Raf üstü anahtarının arızası;
— Veri merkezleri arasındaki optik iletişim kanalının bozulması;
— Tüm operasyonel depolama sisteminin arızalanması.
Bazı durumlarda tehdit modelleri yalnızca altyapı bileşenleri için değil aynı zamanda veri yapısının mantıksal olarak tahrip edilmesiyle ortaya çıkan bir DBMS arızası gibi belirli bilgi sistemleri veya bunların bileşenleri için de yazılır.
Açıklanamayan bir tehdide karşı koruma sağlamak için proje içindeki tüm kararlar gereksizdir.
Düzenleme gereksinimleri
İşlenmekte olan verilerin düzenleyiciler tarafından belirlenen özel kurallara tabi olması durumunda, veri setleri ve işleme/saklama kuralları hakkında bilgi verilmesi gerekmektedir.
RPO/RTO hedefleri
Her türlü korumayı tasarlamak, açıklanan tehditlerin her biri için hedef veri kaybı göstergelerine ve hedef hizmet kurtarma süresine sahip olmayı gerektirir.
İdeal olarak, RPO ve RTO'nun birim zaman başına veri kaybı ve kesinti maliyetleriyle ilişkili olması gerekir.
Kaynak havuzlarına bölünme
Tüm ilk girdi bilgilerini topladıktan sonra ilk adım, veri kümelerini ve IP'yi tehdit modellerine ve düzenleyici gerekliliklere göre havuzlarda gruplandırmaktır. Çeşitli havuzların bölünme türü programlı olarak sistem yazılımı düzeyinde veya fiziksel olarak belirlenir.
Örnekler:
— Kişisel verileri işleyen devre fiziksel olarak diğer sistemlerden tamamen ayrılmıştır;
— Yedeklemeler ayrı bir depolama sisteminde saklanır.
Bu durumda, havuzlar tamamen bağımsız olmayabilir, örneğin, tek bir veri depolama havuzu ve tek bir veri iletim kaynak havuzu kullanan iki bilgi işlem kaynağı havuzu tanımlanır (işlemci gücü + RAM).
İşleme gücü
Özetle, sanallaştırılmış bir veri merkezinin işlem gücü gereksinimleri, sanal işlemcilerin (vCPU'lar) sayısı ve bunların fiziksel işlemciler (pCPU) üzerindeki konsolidasyon oranı cinsinden ölçülür. Bu özel durumda, 1 pCPU = 1 fiziksel işlemci çekirdeği (Hyper-Threading hariç). vCPU'ların sayısı, tanımlanmış tüm kaynak havuzlarında toplanır (her biri kendi birleştirme faktörüne sahip olabilir).
Yüklü sistemler için konsolidasyon katsayısı, mevcut altyapıya dayalı olarak deneysel olarak veya pilot kurulum ve yük testi yoluyla elde edilir. Yüksüz sistemler için “en iyi uygulama” kullanılır. Özellikle VMware ortalama oranı 8:1 olarak belirtiyor.
RAM
Toplam RAM gereksinimi basit toplamayla elde edilir. Aşırı RAM aboneliğinin kullanılması önerilmez.
Depolama kaynakları
Depolama gereksinimleri, tüm havuzların kapasite ve performansa göre toplanmasıyla elde edilir.
Performans gereksinimleri, ortalama okuma/yazma oranı ve gerekirse maksimum yanıt gecikmesi ile birlikte IOPS cinsinden ifade edilir.
Belirli havuzlar veya sistemler için Hizmet Kalitesi (QoS) gereksinimleri ayrı olarak belirtilmelidir.
Veri ağı kaynakları
Veri ağı gereksinimleri, tüm bant genişliği havuzlarının basitçe toplanmasıyla elde edilir.
Belirli havuzlar veya sistemler için Hizmet Kalitesi (QoS) ve gecikme (RTT) gereksinimleri ayrı ayrı belirtilmelidir.
Veri ağı kaynaklarına yönelik gereksinimlerin bir parçası olarak, ağ trafiğinin izolasyonu ve/veya şifrelenmesine yönelik gereksinimler ve tercih edilen mekanizmalar (802.1q, IPSec, vb.) de belirtilmektedir.
Mimari seçimi
Bu kılavuzda x86 mimarisi ve %100 sunucu sanallaştırması dışında herhangi bir seçenek ele alınmamaktadır. Bu nedenle, bilgi işlem alt sistemi mimarisinin seçimi, sunucu sanallaştırma platformunun, sunucu form faktörünün ve genel sunucu yapılandırma gereksinimlerinin seçimine bağlıdır.
Seçimin kilit noktası, veri işleme, depolama ve iletme işlevlerinin ayrıldığı klasik bir yaklaşımın veya yakınsak bir yaklaşımın kullanılmasının kesinliğidir.
klasik mimari veri depolamak ve iletmek için akıllı harici alt sistemlerin kullanımını içerirken, sunucular ortak fiziksel kaynak havuzuna yalnızca işlem gücü ve RAM katkıda bulunur. Aşırı durumlarda, sunucular tamamen anonim hale gelir ve yalnızca kendi disklerine sahip olmakla kalmaz, aynı zamanda bir sistem tanımlayıcısına bile sahip olmazlar. Bu durumda işletim sistemi veya hiper yönetici, yerleşik flash ortamdan veya harici bir veri depolama sisteminden (SAN'dan önyükleme) yüklenir.
Klasik mimari çerçevesinde kanat ve raf seçimi öncelikle aşağıdaki prensiplere göre yapılır:
— Uygun maliyetli (ortalama olarak rafa monte sunucular daha ucuzdur);
— Hesaplama yoğunluğu (bıçaklar için daha yüksek);
— Enerji tüketimi ve ısı dağılımı (bıçakların birim başına özgül birimi daha yüksektir);
— Ölçeklenebilirlik ve kontrol edilebilirlik (bıçaklar genellikle büyük kurulumlar için daha az çaba gerektirir);
- Genişletme kartlarının kullanımı (blade'ler için çok sınırlı seçenek).
Yakınsak mimari (Ayrıca şöyle bilinir hiper yakınsak) veri işleme ve depolama işlevlerinin birleştirilmesini içerir, bu da yerel sunucu disklerinin kullanılmasına ve bunun sonucunda klasik blade form faktörünün terk edilmesine yol açar. Yakınsanmış sistemler için, birden fazla blade sunucusunu ve yerel diski tek bir durumda birleştiren raf sunucuları veya küme sistemleri kullanılır.
CPU/Bellek
Yapılandırmayı doğru hesaplamak için ortamın veya bağımsız kümelerin her birinin yük türünü anlamanız gerekir.
CPU bağlı – performansın işlemci gücüyle sınırlı olduğu bir ortam. RAM eklemek performans (sunucu başına VM sayısı) açısından hiçbir şeyi değiştirmeyecektir.
hafızaya bağlı – ortam RAM ile sınırlıdır. Sunucuda daha fazla RAM, sunucuda daha fazla VM çalıştırmanıza olanak tanır.
GB / MHz (GB / pCPU) – bu belirli yüke göre RAM tüketiminin ve işlemci gücünün ortalama oranı. Belirli bir performans için gerekli bellek miktarını hesaplamak için kullanılabilir veya bunun tersi de geçerlidir.
Sunucu yapılandırma hesaplaması
Öncelikle tüm yük türlerini belirlemeniz ve farklı bilgi işlem havuzlarını farklı kümelere birleştirmeye veya bölmeye karar vermeniz gerekir.
Daha sonra tanımlanan kümelerin her biri için önceden bilinen bir yükte GB/MHz oranı belirlenir. Yük önceden bilinmiyorsa ancak işlemci güç kullanım düzeyine ilişkin kabaca bir anlayış varsa, havuz gereksinimlerini fiziksel olanlara dönüştürmek için standart vCPU:pCPU oranlarını kullanabilirsiniz.
Her küme için vCPU havuzu gereksinimlerinin toplamını katsayıya bölün:
vCPUsum / vCPU:pCPU = pCPUsum – gerekli fiziksel birim sayısı. çekirdekler
pCPUsum / 1.25 = pCPUht – Hyper-Threading için ayarlanan çekirdek sayısı
190 çekirdek / 3.5 TB RAM'e sahip bir Cluster hesaplamanın gerekli olduğunu varsayalım. Aynı zamanda, işlemci gücünün %50'si ve RAM'in %75'i kadar hedef yükü kabul ediyoruz.
PCPU'su
190
CPU kullanımı
%50
Mem
3500
Bellek yardımcı programı
%75
Soket
çekirdek
Srv/CPU
Srv Mem
Srv/Hafıza
2
6
25,3
128
36,5
2
8
19,0
192
24,3
2
10
15,2
256
18,2
2
14
10,9
384
12,2
2
18
8,4
512
9,1
Bu durumda her zaman en yakın tamsayıya yuvarlamayı kullanırız (=ROUNDUP(A1;0)).
Tablodan, hedef göstergeler için çeşitli sunucu yapılandırmalarının dengeli olduğu açıkça görülmektedir:
— 26 sunucu 2*6c / 192 GB
— 19 sunucu 2*10c / 256 GB
— 10 sunucu 2*18c / 512 GB
Bu yapılandırmaların seçimi daha sonra termal paket ve mevcut soğutma, halihazırda kullanılan sunucular veya maliyet gibi ek faktörlere göre yapılmalıdır.
Sunucu yapılandırması seçmenin özellikleri
Geniş VM'ler. Geniş VM'leri barındırmak gerekiyorsa (1 veya daha fazla NUMA düğümüyle karşılaştırılabilir), mümkünse bu tür VM'lerin NUMA düğümü içinde kalmasına izin veren yapılandırmaya sahip bir sunucunun seçilmesi önerilir. Geniş VM'lerin çok sayıda olması durumunda küme kaynaklarının parçalanma tehlikesi vardır ve bu durumda geniş VM'lerin mümkün olduğu kadar yoğun yerleştirilmesine olanak tanıyan sunucular seçilir.
Tek başarısızlık etki alanı boyutu.
Sunucu boyutunun seçimi de tek arıza etki alanının en aza indirilmesi ilkesine dayanmaktadır. Örneğin aşağıdakiler arasında seçim yaparken:
— 3x4*10c / 512 GB
— 6x2*10c / 256 GB
Diğer her şey eşit olduğunda ikinci seçeneği seçmelisiniz, çünkü bir sunucu arızalandığında (veya bakımı yapıldığında) küme kaynaklarının %33'ü değil %17'si kaybolur. Aynı şekilde kazadan etkilenen VM ve IS'lerin sayısı da yarı yarıya azalır.
Performansa dayalı klasik depolama sistemlerinin hesaplanması
Klasik depolama sistemleri, operasyonel önbelleğin etkisi ve operasyonların optimizasyonu hariç tutularak her zaman en kötü senaryo kullanılarak hesaplanır.
Temel performans göstergeleri olarak diskten (IOPSdisk) mekanik performansı alıyoruz:
– 7.2k – 75 IOPS
– 10k – 125 IOPS
– 15k – 175 IOPS
Daha sonra disk havuzundaki disk sayısı aşağıdaki formül kullanılarak hesaplanır: = ToplamIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Nerede:
- ToplamIOPS – disk havuzundan IOPS'de gereken toplam performans
- RW – okuma işlemlerinin yüzdesi
- RAID kalemi – Seçilen RAID seviyesi için RAID cezası
Cihaz RAID ve RAID Cezası hakkında daha fazla bilgiyi burada bulabilirsiniz - и и
Ortaya çıkan disk sayısına bağlı olarak, çok düzeyli depolama seçenekleri de dahil olmak üzere depolama kapasitesi gereksinimlerini karşılayan olası seçenekler hesaplanır.
Depolama katmanı olarak SSD kullanan sistemlerin hesaplanması ayrı olarak ele alınır.
Flash Cache ile hesaplama sistemlerinin özellikleri
Flash Önbellek – flash belleği ikinci düzey önbellek olarak kullanmaya yönelik tüm özel teknolojilerin ortak adı. Bir flaş önbellek kullanıldığında, depolama sistemi genellikle manyetik disklerden sabit bir yük sağlayacak şekilde hesaplanır ve en yüksek değer önbellek tarafından sunulur.
Bu durumda yük profilini ve depolama birimleri bloklarına erişimin yerelleştirme derecesini anlamak gerekir. Flash önbellek, yüksek düzeyde yerelleştirilmiş sorgulara sahip iş yüklerine yönelik bir teknolojidir ve tekdüze olarak yüklenen birimler (analitik sistemleri gibi) için pratik olarak uygulanamaz.
Düşük seviye/orta seviye hibrit sistemlerin hesaplanması
Alt ve orta sınıfların hibrit sistemleri, verilerin belirli bir programa göre seviyeler arasında hareket ettiği çok seviyeli depolamayı kullanır. Aynı zamanda en iyi modeller için çok seviyeli depolama bloğunun boyutu 256 MB'tır. Bu özellikler, birçok kişinin yanlışlıkla inandığı gibi, katmanlı depolama teknolojisini üretkenliği artırmaya yönelik bir teknoloji olarak görmemize izin vermiyor. Düşük ve orta sınıf sistemlerde çok seviyeli depolama, belirgin yük eşitsizliği olan sistemler için depolama maliyetlerini optimize etmeye yönelik bir teknolojidir.
Katmanlı depolama için, ilk olarak en üst katmanın performansı hesaplanırken, en alt depolama katmanının yalnızca eksik depolama kapasitesine katkıda bulunduğu kabul edilir. Hibrit çok katmanlı bir sistem için, alt seviyeden gelen aniden ısınan verilerden kaynaklanan performans düşüşünü telafi etmek amacıyla çok katmanlı havuz için flash önbellek teknolojisinin kullanılması zorunludur.
Katmanlı Disk Havuzunda SSD Kullanma
Çok düzeyli bir disk havuzunda SSD'lerin kullanımı, belirli bir üreticinin flash önbellek algoritmalarının özel uygulamasına bağlı olarak farklılıklar gösterir.
SSD düzeyine sahip bir disk havuzu için depolama politikasının genel uygulaması öncelikle SSD'dir.
Salt Okunur Flash Önbelleği. Salt okunur bir flash önbellek için, SSD'deki depolama katmanı, önbellekten bağımsız olarak yazma işlemlerinin önemli ölçüde yerelleştirilmesiyle birlikte gelir.
Flash Önbelleğini Oku/Yaz. Flash önbellek durumunda, yazma önbelleği boyutu ilk olarak maksimum önbellek boyutuna ayarlanır ve SSD depolama katmanı yalnızca önbellek boyutu yerelleştirilmiş iş yükünün tamamına hizmet vermek için yetersiz olduğunda görünür.
SSD ve önbellek performansı hesaplamaları her seferinde üreticinin tavsiyelerine göre yapılır, ancak her zaman en kötü senaryoya göre yapılır.
Kaynak: habr.com