{"id":35800,"date":"2019-10-31T22:06:24","date_gmt":"2019-10-31T19:06:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/dizajn-virtualizovannogo-tsod\/"},"modified":"2019-10-31T22:06:24","modified_gmt":"2019-10-31T19:06:24","slug":"dizajn-virtualizovannogo-tsod","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","title":{"rendered":"Projekt wirtualizowanego Data Center","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Projekt
\n
\nWprowadzenie<\/b><\/p>\n

System informacyjny z punktu widzenia u\u017cytkownika jest dobrze okre\u015blany w GOST RV 51987 \u2013 \u201esystem zautomatyzowany, kt\u00f3rego wynikiem dzia\u0142ania jest przedstawienie informacji wyj\u015bciowej do p\u00f3\u017aniejszego wykorzystania\u201d. Rozwa\u017caj\u0105c wewn\u0119trzn\u0105 struktur\u0119, w zasadzie ka\u017cdy system informacyjny to system zrealizowanych w kodzie powi\u0105zanych algorytm\u00f3w. W szerokim rozumieniu tezy Turinga-Churcha algorytm (a wi\u0119c system informacyjny) realizuje transformacj\u0119 zestawu danych wej\u015bciowych w zestaw danych wyj\u015bciowych.
\nMo\u017cna nawet stwierdzi\u0107, \u017ce sens istnienia systemu informacyjnego tkwi w transformacji danych wej\u015bciowych. W zwi\u0105zku z tym warto\u015b\u0107 systemu informacyjnego oraz ca\u0142ego kompleksu system\u00f3w informacyjnych okre\u015bla si\u0119 przez warto\u015b\u0107 danych wej\u015bciowych i wyj\u015bciowych.
\nW zwi\u0105zku z tym projektowanie powinno zaczyna\u0107 si\u0119 od danych, dostosowuj\u0105c architektur\u0119 i metody do struktury i znaczenia danych.<\/p>\n

Przechowywane dane<\/b>
\nKluczowym etapem przygotowania do projektowania jest uzyskanie charakterystyki wszystkich zbior\u00f3w danych, kt\u00f3re maj\u0105 by\u0107 przetwarzane i przechowywane. Te charakterystyki obejmuj\u0105:
\n \u2014 Obj\u0119to\u015b\u0107 danych;
\n \u2014 Informacje o cyklu \u017cycia danych (przyrost nowych danych, czas \u017cycia, przetwarzanie przestarza\u0142ych danych);
\n \u2014 Klasyfikacj\u0119 danych z punktu widzenia wp\u0142ywu na podstawowy biznes firmy (w kontek\u015bcie triady poufno\u015bci, integralno\u015bci, dost\u0119pno\u015bci) wraz z wska\u017anikami finansowymi (np. koszt utraty danych w ostatniej godzinie);
\n \u2014 Geografia przetwarzania danych (fizyczna lokalizacja system\u00f3w przetwarzania);
\n \u2014 Wymagania regulacyjne dla ka\u017cdej klasy danych (np. FZ-152, PCI DSS).<\/p>\n

<\/a><\/noindex><\/p>\n

Systemy informacyjne<\/b><\/p>\n

Dane nie tylko s\u0105 przechowywane, ale r\u00f3wnie\u017c przetwarzane (transformowane) przez systemy informacyjne. Nast\u0119pnym krokiem po uzyskaniu charakterystyki danych jest jak najbardziej pe\u0142na inwentaryzacja system\u00f3w informacyjnych, ich cech architektonicznych, wzajemnych zale\u017cno\u015bci i wymaga\u0144 dotycz\u0105cych infrastruktury w odniesieniu do czterech rodzaj\u00f3w zasob\u00f3w:
\n \u2014 Moc obliczeniowa procesora;
\n \u2014 Obj\u0119to\u015b\u0107 pami\u0119ci operacyjnej;
\n \u2014 Wymagania dotycz\u0105ce obj\u0119to\u015bci i wydajno\u015bci systemu przechowywania danych;
\n \u2014 Wymagania dotycz\u0105ce sieci transmisyjnej danych (kana\u0142y zewn\u0119trzne, kana\u0142y mi\u0119dzy komponentami systemu informacyjnego).
\nWymagania powinny by\u0107 opracowane dla ka\u017cdej us\u0142ugi\/mikrous\u0142ugi w sk\u0142adzie systemu informatycznego.
\nOsobno nale\u017cy podkre\u015bli\u0107 konieczno\u015b\u0107 posiadania danych dotycz\u0105cych wp\u0142ywu systemu informatycznego na g\u0142\u00f3wny biznes firmy, w postaci koszt\u00f3w przestoju systemu informatycznego (w rubrach za godzin\u0119).<\/p>\n

Model zagro\u017ce\u0144<\/b><\/p>\n

Obowi\u0105zkowo musi by\u0107 dost\u0119pny formalny model zagro\u017ce\u0144, od kt\u00f3rych planuje si\u0119 ochron\u0119 danych\/us\u0142ug. Model zagro\u017ce\u0144 obejmuje nie tylko aspekty poufno\u015bci, ale tak\u017ce integralno\u015bci i dost\u0119pno\u015bci. Tzn. na przyk\u0142ad:
\n \u2014 Awaria fizycznego serwera;
\n \u2014 Awaria prze\u0142\u0105cznika top-of-the-rack;
\n \u2014 Zerwanie optycznego kana\u0142u komunikacyjnego mi\u0119dzy centr\u00f3w danych;
\n \u2014 Awaria pami\u0119ci masowej w ca\u0142o\u015bci.
\nW niekt\u00f3rych przypadkach modele zagro\u017ce\u0144 tworzone s\u0105 nie tylko dla komponent\u00f3w infrastruktury, ale r\u00f3wnie\u017c dla konkretnych system\u00f3w informatycznych lub ich komponent\u00f3w, jak na przyk\u0142ad awaria systemu zarz\u0105dzania baz\u0105 danych z logicznym zniszczeniem struktury danych.
\nWszystkie rozwi\u0105zania w ramach projektu dotycz\u0105ce ochrony przed nieopisanym zagro\u017ceniem s\u0105 zb\u0119dne.<\/p>\n

Wymagania regulacyjne<\/b><\/p>\n

Je\u015bli przetwarzane dane podlegaj\u0105 specjalnym zasadom ustalanym przez organy regulacyjne, niezb\u0119dne jest posiadanie informacji o zestawach danych oraz zasadach przetwarzania\/przechowywania.<\/p>\n

Wska\u017aniki celowe RPO\/RTO<\/b><\/p>\n

Projektowanie jakiejkolwiek ochrony wymaga posiadania wska\u017anik\u00f3w celowej utraty danych oraz celowego czasu przywracania us\u0142ugi dla ka\u017cdego z opisanych zagro\u017ce\u0144.
\nW idealnym przypadku RPO i RTO powinny mie\u0107 powi\u0105zane koszty utraty danych i przestoju w jednostce czasu.<\/p>\n

\"Projekt
\n
\nPodzia\u0142 na pule zasob\u00f3w<\/b><\/p>\n

Po zebraniu wszystkich pocz\u0105tkowych danych, pierwszym krokiem jest grupowanie zestaw\u00f3w danych i system\u00f3w informatycznych w pule, w oparciu o modele zagro\u017ce\u0144 oraz wymagania regulacyjne. Okre\u015bla si\u0119 spos\u00f3b podzia\u0142u r\u00f3\u017cnych pul \u2013 programowo na poziomie oprogramowania systemowego lub fizycznie.
\nPrzyk\u0142ady:
\n \u2014 Kontur przetwarzaj\u0105cy dane osobowe jest ca\u0142kowicie fizycznie oddzielony od innych system\u00f3w;
\n \u2014 Kopie zapasowe s\u0105 przechowywane na oddzielnym systemie pami\u0119ci masowej.<\/p>\n

Przy tym pule mog\u0105 by\u0107 cz\u0119\u015bciowo niezale\u017cne, na przyk\u0142ad definiuje si\u0119 dwa pule zasob\u00f3w obliczeniowych (moc obliczeniowa + pami\u0119\u0107 RAM), kt\u00f3re korzystaj\u0105 z jednego zbioru zasob\u00f3w pami\u0119ci masowej oraz jednego zestawu zasob\u00f3w przesy\u0142ania danych.<\/p>\n

Moc obliczeniowa<\/b><\/p>\n

\"Projekt
\n
\nAbstrakcyjne potrzeby w zakresie mocy procesora w wirtualizowanym centrum danych mierzy si\u0119 liczb\u0105 wirtualnych procesor\u00f3w (vCPU) oraz wsp\u00f3\u0142czynnikiem konsolidacji w fizycznych procesorach (pCPU). W tym konkretnym przypadku 1 pCPU = 1 fizyczne rdze\u0144 procesora (nie uwzgl\u0119dniaj\u0105c Hyper-Threading). Liczba vCPU sumuje si\u0119 dla wszystkich okre\u015blonych pul zasob\u00f3w (z kt\u00f3rych ka\u017cda mo\u017ce mie\u0107 sw\u00f3j wsp\u00f3\u0142czynnik konsolidacji).
\nWsp\u00f3\u0142czynnik konsolidacji dla obci\u0105\u017conych system\u00f3w uzyskuje si\u0119 empirycznie, w oparciu o ju\u017c istniej\u0105c\u0105 infrastruktur\u0119 lub podczas pilota\u017cowej instalacji oraz test\u00f3w obci\u0105\u017ceniowych. Dla nieobci\u0105\u017conych system\u00f3w stosuje si\u0119 \"najlepsze praktyki\". W szczeg\u00f3lno\u015bci VMware podaje \u015bredni wsp\u00f3\u0142czynnik 8:1.<\/p>\n

Pami\u0119\u0107 operacyjna<\/b><\/p>\n

Og\u00f3lna potrzeba pami\u0119ci operacyjnej uzyskiwana jest przez proste sumowanie. U\u017cycie przeszeregowania pami\u0119ci operacyjnej nie jest zalecane.<\/p>\n

Zasoby magazynowania<\/b><\/p>\n

Wymagania dotycz\u0105ce zasob\u00f3w magazynowych uzyskuje si\u0119 poprzez proste sumowanie wszystkich pul pod wzgl\u0119dem pojemno\u015bci i wydajno\u015bci.
\nWymagania dotycz\u0105ce wydajno\u015bci wyra\u017caj\u0105 si\u0119 w IOPS w po\u0142\u0105czeniu ze \u015brednim wsp\u00f3\u0142czynnikiem odczytu\/zapisu i w razie potrzeby maksymalnym op\u00f3\u017anieniem odpowiedzi.
\nOsobno nale\u017cy okre\u015bli\u0107 wymagania dotycz\u0105ce zapewnienia jako\u015bci us\u0142ug (QoS) dla okre\u015blonych pul lub system\u00f3w.<\/p>\n

Zasoby sieci przesy\u0142owej danych<\/b><\/p>\n

Wymagania dotycz\u0105ce sieci przesy\u0142owej danych uzyskuje si\u0119 przez proste sumowanie wszystkich pul przepustowo\u015bci.
\nOsobno nale\u017cy okre\u015bli\u0107 wymagania dotycz\u0105ce zapewnienia jako\u015bci us\u0142ug (QoS) oraz op\u00f3\u017anie\u0144 (RTT) dla okre\u015blonych pul lub system\u00f3w.
\nW ramach wymaga\u0144 dotycz\u0105cych zasob\u00f3w sieci przesy\u0142owej danych okre\u015blane s\u0105 r\u00f3wnie\u017c wymagania dotycz\u0105ce izolacji i\/lub szyfrowania ruchu sieciowego oraz preferowanych mechanizm\u00f3w (802.1q, IPSec itd.).<\/p>\n

Wyb\u00f3r architektury<\/b><\/p>\n

W ramach tego przewodnika nie rozpatruje si\u0119 innych wybor\u00f3w poza architektur\u0105 x86 i 100% wirtualizacj\u0105 serwer\u00f3w. Dlatego wyb\u00f3r architektury systemu obliczeniowego sprowadza si\u0119 do wyboru platformy wirtualizacji serwer\u00f3w, formatu serwer\u00f3w oraz og\u00f3lnych wymaga\u0144 dotycz\u0105cych konfiguracji serwer\u00f3w.<\/p>\n

Kluczowym aspektem wyboru jest jasno okre\u015blona decyzja, czy stosowa\u0107 klasyczne podej\u015bcie z podzia\u0142em funkcji przetwarzania, magazynowania i przesy\u0142ania danych, czy podej\u015bcie konwergentne.<\/p>\n

Klasyczna architektura<\/i> zak\u0142ada wykorzystanie inteligentnych zewn\u0119trznych system\u00f3w przechowywania i przesy\u0142ania danych, podczas gdy serwery wnosi\u0142yby do og\u00f3lnej puli zasob\u00f3w fizycznych jedynie moc procesora i pami\u0119\u0107 RAM. W skrajnych przypadkach serwery staj\u0105 si\u0119 ca\u0142kowicie anonimowe, nie maj\u0105ce nie tylko w\u0142asnych dysk\u00f3w, ale nawet identyfikatora systemowego. W takim przypadku u\u017cywa si\u0119 uruchamiania systemu operacyjnego lub hyperwizora z wbudowanych no\u015bnik\u00f3w flash lub z zewn\u0119trznego systemu przechowywania danych (boot from SAN).
\nW ramach klasycznej architektury wyb\u00f3r mi\u0119dzy ostrzami (blade) a serwerami stoj\u0105cymi (rack) dokonywany jest przede wszystkim wed\u0142ug nast\u0119puj\u0105cych zasad:
\n \u2014 Efektywno\u015b\u0107 ekonomiczna (\u015brednio serwery stoj\u0105ce s\u0105 ta\u0144sze);
\n \u2014 G\u0119sto\u015b\u0107 obliczeniowa (blady maj\u0105 wy\u017csz\u0105 g\u0119sto\u015b\u0107);
\n \u2014 Zu\u017cycie energii i wydzielanie ciep\u0142a (u ostrzy jest wy\u017csze na jednostk\u0119);
\n \u2014 Skalowalno\u015b\u0107 i zarz\u0105dzalno\u015b\u0107 (ostrza w og\u00f3le wymagaj\u0105 mniej wysi\u0142ku przy du\u017cych instalacjach);
\n \u2014 U\u017cycie kart rozszerze\u0144 (dla ostrzy dost\u0119pny jest bardzo ograniczony wyb\u00f3r).
\nArchitektura konwergentna<\/i> (znana r\u00f3wnie\u017c jako hiperkonwergentna<\/i>) zak\u0142ada po\u0142\u0105czenie funkcji przetwarzania i przechowywania danych, co prowadzi do u\u017cycia lokalnych dysk\u00f3w serwer\u00f3w i tym samym do rezygnacji z formatu klasycznych ostrzy. W systemach konwergentnych u\u017cywa si\u0119 albo serwer\u00f3w stoj\u0105cych, albo system\u00f3w klastrowych, kt\u00f3re \u0142\u0105cz\u0105 w jednej obudowie kilka serwer\u00f3w ostrzy i lokalne dyski.<\/p>\n

CPU \/ Pami\u0119\u0107 <\/b><\/p>\n

Aby poprawnie obliczy\u0107 konfiguracj\u0119, nale\u017cy zrozumie\u0107 rodzaj obci\u0105\u017cenia dla \u015brodowiska lub ka\u017cdego z niezale\u017cnych klastr\u00f3w.
\nOgraniczenie CPU<\/i> \u2013 \u015brodowisko ograniczone moc\u0105 procesora. Dodanie pami\u0119ci RAM nie zmieni nic w zakresie wydajno\u015bci (liczby maszyn wirtualnych na serwerze).
\nOgraniczenie pami\u0119ci<\/i> \u2013 \u015brodowisko ograniczone pami\u0119ci\u0105 RAM. Wi\u0119ksza ilo\u015b\u0107 pami\u0119ci RAM na serwerze pozwala na uruchomienie wi\u0119kszej liczby maszyn wirtualnych na serwerze.
\nGB \/ MHz (GB \/ pCPU) \u2013 \u015bredni stosunek zu\u017cycia pami\u0119ci RAM i mocy procesora dla tego konkretnego obci\u0105\u017cenia. Mo\u017ce by\u0107 u\u017cyty do oblicze\u0144 potrzebnej ilo\u015bci pami\u0119ci przy zadanej wydajno\u015bci i odwrotnie. <\/p>\n

Obliczenie konfiguracji serwera<\/b><\/p>\n

\"Projekt
\n
\nNa pocz\u0105tku nale\u017cy okre\u015bli\u0107 wszystkie rodzaje obci\u0105\u017cenia i podj\u0105\u0107 decyzj\u0119 o \u0142\u0105czeniu lub rozdzielaniu r\u00f3\u017cnych pul obliczeniowych w r\u00f3\u017cnych klastrach.
\nNast\u0119pnie dla ka\u017cdego z okre\u015blonych klastr\u00f3w ustala si\u0119 proporcj\u0119 GB \/ MHz przy znanym z g\u00f3ry obci\u0105\u017ceniu. Je\u015bli obci\u0105\u017cenie nie jest znane z wyprzedzeniem, ale jest przybli\u017cone zrozumienie poziomu obci\u0105\u017cenia mocy procesora, mo\u017cna u\u017cy\u0107 standardowych wsp\u00f3\u0142czynnik\u00f3w vCPU:pCPU do przeliczenia wymaga\u0144 pul na fizyczne. <\/p>\n

Dla ka\u017cdego klastra sum\u0119 wymaga\u0144 pul vCPU dzielimy przez wsp\u00f3\u0142czynnik:
\nvCPU_sum \/ vCPU:pCPU = pCPU_sum \u2013 wymagane liczba rdzeni fizycznych
\npCPU_sum \/ 1.25 = pCPU_ht \u2013 liczba rdzeni z korekt\u0105 na Hyper-Threading
\nZa\u0142\u00f3\u017cmy, \u017ce nale\u017cy wykona\u0107 obliczenia klastra na 190 rdzeni \/ 3.5TB RAM. Przyjmujemy docelowe obci\u0105\u017cenie mocy procesora na poziomie 50% oraz 75% dla pami\u0119ci operacyjnej.<\/p>\n

pCPU<\/b>
\n190
\nWykorzystanie CPU<\/b>
\n50%<\/p>\n

Mem<\/b>
\n3500
\nWykorzystanie pami\u0119ci<\/b>
\n75%<\/p>\n

Gniazdo<\/b>
\nRdze\u0144<\/b>
\nSrv \/ CPU<\/b>
\nSrv Mem<\/b>
\nSrv \/ Mem<\/b><\/p>\n

2
\n6
\n25,3
\n128
\n36,5<\/p>\n

2
\n8
\n19,0
\n192
\n24,3<\/p>\n

2
\n10
\n15,2
\n256
\n18,2<\/p>\n

2
\n14
\n10,9
\n384
\n12,2<\/p>\n

2
\n18
\n8,4
\n512
\n9,1<\/p>\n

W takim przypadku zawsze u\u017cywamy zaokr\u0105glenia do najbli\u017cszej liczby ca\u0142kowitej w g\u00f3r\u0119 (=ROUNDUP(A1;0)).
\nZ tabeli wynika, \u017ce zoptymalizowane pod k\u0105tem cel\u00f3w s\u0105 r\u00f3\u017cne konfiguracje serwer\u00f3w:
\n \u2014 26 serwer\u00f3w 2*6c \/ 192 GB
\n \u2014 19 serwer\u00f3w 2*10c \/ 256 GB
\n \u2014 10 serwer\u00f3w 2*18c \/ 512 GB <\/p>\n

Wyb\u00f3r spo\u015br\u00f3d tych konfiguracji musi by\u0107 dokonany na podstawie dodatkowych czynnik\u00f3w, takich jak pakiet cieplny i dost\u0119pne ch\u0142odzenie, ju\u017c u\u017cywane serwery lub koszt.<\/p>\n

Cechy wyboru konfiguracji serwera<\/b><\/p>\n

Szerokie VM. W przypadku potrzeby rozmieszczenia szerokich VM (por\u00f3wnywalnych z 1 w\u0119z\u0142em NUMA i wi\u0119kszymi) zaleca si\u0119 wyb\u00f3r serwera z konfiguracj\u0105, kt\u00f3ra umo\u017cliwia utrzymanie takich VM w obr\u0119bie w\u0119z\u0142a NUMA. Przy du\u017cej liczbie szerokich VM istnieje ryzyko fragmentacji zasob\u00f3w klastra, w takim przypadku wybierane s\u0105 serwery, kt\u00f3re umo\u017cliwiaj\u0105 maksymalne zag\u0119szczenie szerokich VM.<\/p>\n

Rozmiar domeny pojedynczej awarii.<\/b> <\/p>\n

Wyb\u00f3r rozmiaru serwera r\u00f3wnie\u017c odbywa si\u0119 zgodnie z zasad\u0105 minimalizacji domeny pojedynczej awarii. Na przyk\u0142ad przy wyborze mi\u0119dzy:
\n \u2014 3 x 4*10c \/ 512 GB
\n \u2014 6 x 2*10c \/ 256 GB
\nPrzy innych r\u00f3wnych warunkach nale\u017cy wybiera\u0107 drug\u0105 opcj\u0119, poniewa\u017c przy awarii jednego serwera (lub serwisie) nie traci si\u0119 33% zasob\u00f3w klastra, lecz 17%. Tak samo o po\u0142ow\u0119 zmniejsza si\u0119 liczba VM i IS, na kt\u00f3rych odzwierciedlona by\u0142a awaria.<\/p>\n

Obliczenia tradycyjnego systemu pami\u0119ci masowej wed\u0142ug wydajno\u015bci<\/b><\/p>\n

\"Projekt
\n
\nTradycyjny system pami\u0119ci masowej zawsze obliczany jest wed\u0142ug najgorszego scenariusza, wykluczaj\u0105c wp\u0142yw pami\u0119ci podr\u0119cznej i optymalizacji operacji.
\nJako podstawowe wska\u017aniki wydajno\u015bci przyjmujemy wydajno\u015b\u0107 mechaniczn\u0105 dysku (IOPSdisk):
\n \u2014 7.2k \u2013 75 IOPS
\n \u2014 10k \u2013 125 IOPS
\n \u2014 15k \u2013 175 IOPS<\/p>\n

Nast\u0119pnie liczba dysk\u00f3w w puli oblicza si\u0119 wed\u0142ug nast\u0119puj\u0105cego wzoru: = TotalIOPS * ( RW + (1 \u2013RW) * RAIDPen) \/ IOPSdisk<\/i>. Gdzie:
\n \u2014 TotalIOPS<\/i> \u2013 ca\u0142kowita wymagana wydajno\u015b\u0107 w IOPS z puli dysk\u00f3w
\n \u2014 RW<\/i> \u2013 procentowa warto\u015b\u0107 operacji odczytu
\n \u2014 RAIDpen<\/i> \u2013 kara RAID dla wybranego poziomu RAID<\/p>\n

Wi\u0119cej informacji na temat urz\u0105dzenia RAID i kary RAID mo\u017cna znale\u017a\u0107 tutaj \u2014 Wydajno\u015b\u0107 system\u00f3w pami\u0119ci masowej. Cz\u0119\u015b\u0107 pierwsza.<\/a><\/noindex> i Wydajno\u015b\u0107 system\u00f3w pami\u0119ci masowej. Cz\u0119\u015b\u0107 druga.<\/a><\/noindex> i Wydajno\u015b\u0107 system\u00f3w pami\u0119ci masowej. Cz\u0119\u015b\u0107 trzecia.<\/a><\/noindex><\/p>\n

Na podstawie uzyskanej liczby dysk\u00f3w oblicza si\u0119 mo\u017cliwe warianty, spe\u0142niaj\u0105ce wymagania dotycz\u0105ce pojemno\u015bci przechowywania, w tym opcje z wielopoziomowym przechowywaniem.
\nObliczenie system\u00f3w z wykorzystaniem SSD jako poziomu przechowywania rozpatrywane jest oddzielnie.
\nSpecyfika obliczania system\u00f3w z Flash Cache
\n<\/b><\/p>\n

Flash Cache<\/i> \u2013 og\u00f3lna nazwa dla wszystkich firmowych technologii wykorzystania pami\u0119ci flash jako pami\u0119ci podr\u0119cznej drugiego poziomu. Przy u\u017cyciu pami\u0119ci podr\u0119cznej flash, systemy pami\u0119ci masowej zazwyczaj obliczaj\u0105 w celu zapewnienia obci\u0105\u017cenia z dysk\u00f3w magnetycznych, podczas gdy szczytowe obci\u0105\u017cenie obs\u0142uguje pami\u0119\u0107 podr\u0119czna.
\nPrzy tym \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u043f\u0440\u043e\u0444\u0438\u043b\u044f \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 i stopnia lokalizacji zapyta\u0144 do blok\u00f3w wolumen\u00f3w storage. Cache flash to technologia dla obci\u0105\u017ce\u0144 z wysok\u0105 lokalizacj\u0105 \u017c\u0105da\u0144 i praktycznie niewykonalna dla r\u00f3wnomiernie obci\u0105\u017conych wolumen\u00f3w (jak na przyk\u0142ad w systemach analitycznych). <\/p>\n

Obliczenia system\u00f3w hybrydowych low-end \/ mid-range<\/b><\/p>\n

Hybrydowe systemy klasy podstawowej i \u015bredniej wykorzystuj\u0105 wielowarstwowe przechowywanie z przenoszeniem danych pomi\u0119dzy warstwami zgodnie z harmonogramem. Przy tym rozmiar bloku przechowywania wielowarstwowego w najlepszych modelach wynosi 256 MB. Te cechy sprawiaj\u0105, \u017ce technologia przechowywania wielowarstwowego nie mo\u017ce by\u0107 uznawana za technologi\u0119 zwi\u0119kszaj\u0105c\u0105 wydajno\u015b\u0107, jak b\u0142\u0119dnie s\u0105dzi wielu. Przechowywanie wielowarstwowe w systemach klasy podstawowej i \u015bredniej to technologia optymalizacji koszt\u00f3w przechowywania dla system\u00f3w o wyra\u017anej nier\u00f3wnomierno\u015bci obci\u0105\u017cenia.<\/p>\n

Dla wielopoziomowego przechowywania oblicza si\u0119 przede wszystkim wydajno\u015b\u0107 na g\u00f3rnym poziomie, podczas gdy dolny poziom przechowywania uznawany jest tylko za dostarczaj\u0105cy brakuj\u0105c\u0105 pojemno\u015b\u0107. W przypadku hybrydowego systemu wielopoziomowego obowi\u0105zkowe jest wykorzystanie technologii pami\u0119ci podr\u0119cznej flash dla wielopoziomowej puli, w celu zrekompensowania spadku wydajno\u015bci dla nag\u0142ych danych z dolnego poziomu.<\/p>\n

Wykorzystanie SSD w wielopoziomowej puli dysk\u00f3w<\/b><\/p>\n

\"Projekt
\n
\nWykorzystanie SSD w wielopoziomowej puli dysk\u00f3w ma wariacje, w zale\u017cno\u015bci od specyfiki realizacji algorytm\u00f3w pami\u0119ci podr\u0119cznej flash przez danego producenta.
\nOg\u00f3lna praktyka polityki przechowywania dla puli dysk\u00f3w z poziomem SSD \u2014 SSD first.
\nPami\u0119\u0107 podr\u0119czna flash tylko do odczytu.<\/i> Dla pami\u0119ci podr\u0119cznej Flash tylko do odczytu poziom przechowywania na SSD pojawia si\u0119 przy znacznej lokalizacji operacji zapisu, niezale\u017cnie od pami\u0119ci podr\u0119cznej.
\nOdczyt \/ Zapis Pami\u0119ci Flash.<\/i> W przypadku pami\u0119ci podr\u0119cznej Flash do zapisu najpierw ustala si\u0119 maksymalny rozmiar pami\u0119ci podr\u0119cznej, a poziom przechowywania na SSD pojawia si\u0119 tylko przy niedoborze rozmiaru pami\u0119ci podr\u0119cznej do obs\u0142ugi ca\u0142ego zlokalizowanego obci\u0105\u017cenia.
\nObliczenie wydajno\u015bci SSD i pami\u0119ci podr\u0119cznej przeprowadzane jest za ka\u017cdym razem na podstawie zalece\u0144 producenta, ale zawsze dla najgorszego scenariusza.
\n
\u0179r\u00f3d\u0142o: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0441 \u0442\u043e\u0447\u043a\u0438 \u0437\u0440\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f \u0445\u043e\u0440\u043e\u0448\u043e \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u044f\u0435\u0442\u0441\u044f \u0432 \u0413\u041e\u0421\u0422 \u0420\u0412 51987 \u2014 \u00ab\u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u043e\u043c \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u043e\u0442\u043e\u0440\u043e\u0439 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0432\u044b\u0445\u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0434\u043b\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f\u00bb. \u0415\u0441\u043b\u0438 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0442\u044c \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u044e\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443, \u0442\u043e \u043f\u043e \u0441\u0443\u0442\u0438 \u043b\u044e\u0431\u0430\u044f \u0418\u0421 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439 \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0445 \u0432 \u043a\u043e\u0434\u0435 \u0432\u0437\u0430\u0438\u043c\u043e\u0441\u0432\u044f\u0437\u0430\u043d\u043d\u044b\u0445 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c\u043e\u0432. \u0412 \u0448\u0438\u0440\u043e\u043a\u043e\u043c \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u0438 \u0442\u0435\u0437\u0438\u0441\u0430 \u0422\u044c\u044e\u0440\u0438\u043d\u0433\u0430-\u0427\u0435\u0440\u0447\u0430 \u0430\u043b\u0433\u043e\u0440\u0438\u0442\u043c (\u0430 \u0441\u043b-\u043d\u043e \u0418\u0421) \u043e\u0441\u0443\u0449\u0435\u0441\u0442\u0432\u043b\u044f\u0435\u0442 \u0442\u0440\u0430\u043d\u0441\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044e \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u0430 \u0432\u0445\u043e\u0434\u043d\u044b\u0445 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26806,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35800","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Projekt wirtualizowanego DC | ProHoster","description":"Wprowadzenie System informacji z punktu.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0438\u0437\u0430\u0439\u043d \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u043e\u0433\u043e \u0426\u041e\u0414 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0441 \u0442\u043e\u0447\u043a\u0438.","og:url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/dizajn-virtualizovannogo-tsod","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:06:24+00:00","article:modified_time":"2019-10-31T19:06:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35800","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 00:48:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:06:24","updated":"2026-01-22 00:48:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/35800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=35800"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/35800\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/26806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=35800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=35800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=35800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}