Танилцуулга
Хэрэглэгчийн үүднээс мэдээллийн системийг ГОСТ RV 51987-д маш сайн тодорхойлсон байдаг - "үр дүн нь дараагийн хэрэглээнд зориулж гаралтын мэдээллийг танилцуулах автоматжуулсан систем". Хэрэв бид дотоод бүтцийг авч үзвэл үндсэндээ аливаа IS нь кодонд хэрэгжсэн харилцан уялдаатай алгоритмуудын систем юм. Тюринг-Сүмийн дипломын ажлын өргөн утгаараа алгоритм (эсвэл IS) нь оролтын өгөгдлийг гаралтын багц болгон хувиргадаг.
Оролтын өгөгдлийг хувиргах нь мэдээллийн систем оршин тогтнохын утга учир гэж хэлж болно. Үүний дагуу IS ба бүх IS цогцолборын утгыг оролт, гаралтын өгөгдлийн утгаар тодорхойлно.
Үүний үндсэн дээр дизайн эхэлж, өгөгдөлд суурилсан байх ёстой бөгөөд өгөгдлийн бүтэц, ач холбогдлыг харгалзан архитектур, аргуудыг тохируулах ёстой.
Хадгалагдсан өгөгдөл
Дизайныг бэлтгэх гол үе шат бол боловсруулах, хадгалахаар төлөвлөж буй бүх мэдээллийн багцын шинж чанарыг олж авах явдал юм. Эдгээр шинж чанарууд нь:
- Өгөгдлийн хэмжээ;
— Өгөгдлийн амьдралын мөчлөгийн талаарх мэдээлэл (шинэ өгөгдлийн өсөлт, ашиглалтын хугацаа, хуучирсан өгөгдлийг боловсруулах);
— Өгөгдлийг харах өнцгөөс нь ангилах компанийн үндсэн бизнест үзүүлэх нөлөө (нууцлал, бүрэн бүтэн байдал, хүртээмжийн гурвал) санхүүгийн үзүүлэлтүүдийн хамт (жишээ нь, сүүлийн нэг цагийн өгөгдөл алдагдлын зардал);
— Мэдээлэл боловсруулах газарзүй (боловсруулах системийн физик байршил);
— Мэдээллийн ангилал тус бүрийн зохицуулалтын шаардлага (жишээлбэл, Холбооны хууль-152, PCI DSS).
Мэдээллийн систем
Мэдээллийг мэдээллийн системээр зөвхөн хадгалахаас гадна боловсруулдаг (хувиргадаг). Мэдээллийн шинж чанарыг олж авсны дараа дараагийн алхам бол мэдээллийн систем, тэдгээрийн архитектурын шинж чанар, харилцан хамаарал, дэд бүтцийн хэрэгцээг хангах дөрвөн төрлийн нөөцийн ердийн нэгжүүдийн хамгийн бүрэн тооллого юм.
- Процессорын тооцоолох хүчин чадал;
- RAM-ийн хэмжээ;
— Мэдээлэл хадгалах системийн хэмжээ, гүйцэтгэлд тавигдах шаардлага;
— Мэдээлэл дамжуулах сүлжээнд тавигдах шаардлага (гадаад суваг, IS бүрэлдэхүүн хэсгүүдийн хоорондох суваг).
Энэ тохиолдолд IS-ийн нэг хэсэг болох үйлчилгээ/микро үйлчилгээ тус бүрд тавигдах шаардлага байх ёстой.
Зөв дизайн хийхийн тулд IS-ийн сул зогсолтын зардал (цагт рубль) хэлбэрээр компанийн үндсэн бизнест IS-ийн нөлөөллийн талаархи мэдээлэл байх шаардлагатай гэдгийг тусад нь тэмдэглэх нь зүйтэй.
Аюул заналхийллийн загвар
Өгөгдөл/үйлчилгээг хамгаалахаар төлөвлөж буй аюул заналхийллийн албан ёсны загвар байх ёстой. Түүнчлэн, аюул заналхийллийн загвар нь зөвхөн нууцлалын талуудаас гадна бүрэн бүтэн байдал, хүртээмжтэй байдлыг агуулдаг. Тэдгээр. Жишээлбэл:
- Физик серверийн доголдол;
— Дээд талын шилжүүлэгчийн эвдрэл;
— Мэдээллийн төвүүдийн хоорондын оптик холбооны сувгийг тасалдуулах;
- Үйл ажиллагааны бүхэл бүтэн хадгалах системийн доголдол.
Зарим тохиолдолд аюул заналхийллийн загваруудыг зөвхөн дэд бүтцийн бүрэлдэхүүн хэсгүүдэд төдийгүй тодорхой мэдээллийн системүүд эсвэл тэдгээрийн бүрэлдэхүүн хэсгүүдэд зориулж бичсэн байдаг, тухайлбал өгөгдлийн бүтцийг логикоор устгасан DBMS-ийн алдаа.
Төслийн хүрээнд тодорхойгүй аюулаас хамгаалах бүх шийдвэр нь шаардлагагүй юм.
Зохицуулалтын шаардлага
Хэрэв боловсруулж буй өгөгдөл нь зохицуулагчдаас тогтоосон тусгай дүрмийн дагуу байвал мэдээллийн багц, боловсруулах/хадгалах дүрмийн талаарх мэдээлэл шаардлагатай.
RPO/RTO зорилтууд
Ямар ч төрлийн хамгаалалтыг зохион бүтээхийн тулд тодорхойлсон аюул тус бүрийн хувьд зорилтот өгөгдөл алдагдах үзүүлэлт, зорилтот үйлчилгээг сэргээх хугацаа шаардагдана.
Хамгийн тохиромжтой нь RPO болон RTO нь нэгж хугацаанд өгөгдлийн алдагдал болон сул зогсолттой холбоотой зардалтай байх ёстой.
Нөөцийн санд хуваах
Оролтын бүх мэдээллийг цуглуулсны дараа эхний алхам бол аюул заналхийллийн загвар, зохицуулалтын шаардлагад үндэслэн мэдээллийн багц болон IP-г бүлэглэх явдал юм. Төрөл бүрийн усан сангуудын хуваагдлын төрлийг системийн програм хангамжийн түвшинд эсвэл физик байдлаар тодорхойлдог.
жишээ нь:
— Хувийн мэдээллийг боловсруулах хэлхээ нь бусад системээс биет байдлаар бүрэн тусгаарлагдсан;
— Нөөцлөлтийг тусдаа хадгалах системд хадгалдаг.
Энэ тохиолдолд сангууд нь бүрэн бус бие даасан байж болно, жишээлбэл, тооцоолох нөөцийн хоёр санг (процессорын хүч + RAM) тодорхойлсон бөгөөд эдгээр нь нэг өгөгдөл хадгалах сан, нэг өгөгдөл дамжуулах нөөцийн санг ашигладаг.
Боловсруулах хүч
Хураангуй, виртуалчлагдсан өгөгдлийн төвийн боловсруулах хүчин чадлын хэрэгцээг виртуал процессоруудын тоо (vCPU) болон физик процессорууд (pCPU) дээр нэгтгэх харьцаагаар хэмждэг. Энэ тохиолдолд 1 pCPU = 1 физик процессорын цөм (Hyper-Threading-аас бусад). vCPU-ийн тоог бүх тодорхойлсон нөөцийн сан (тус бүр нь өөрийн нэгтгэх хүчин зүйлтэй байж болно) дээр нэгтгэсэн болно.
Ачаалал ихтэй системүүдийн нэгдлийн коэффициентийг одоо байгаа дэд бүтцэд тулгуурлан эсвэл туршилтын суурилуулалт, ачааллын туршилтаар олж авдаг. Ачаалалгүй системүүдийн хувьд "шилдэг туршлагыг" ашигладаг. Тодруулбал, VMware дундаж харьцааг 8:1 гэж иш татдаг.
Үйлдлийн санах ой
Нийт RAM-ийн шаардлагыг энгийн нийлбэрээр олж авдаг. RAM хэтрүүлэн ашиглахыг зөвлөдөггүй.
Хадгалах нөөц
Хадгалалтын шаардлагыг бүх усан сангуудыг хүчин чадал, гүйцэтгэлээр нь нэгтгэх замаар олж авдаг.
Гүйцэтгэлийн шаардлагыг дундаж унших/бичих харьцаа, шаардлагатай бол хариу өгөх хамгийн их хоцрогдолтой хослуулсан IOPS-д илэрхийлнэ.
Тодорхой усан сан эсвэл системд тавигдах үйлчилгээний чанар (QoS) шаардлагыг тусад нь зааж өгөх ёстой.
Өгөгдлийн сүлжээний нөөц
Өгөгдлийн сүлжээний шаардлагыг бүх зурвасын өргөнийг нэгтгэх замаар олж авдаг.
Тодорхой усан сан эсвэл системд тавигдах үйлчилгээний чанар (QoS) ба хоцролт (RTT) шаардлагуудыг тусад нь зааж өгөх ёстой.
Мэдээллийн сүлжээний нөөцөд тавигдах шаардлагуудын нэг хэсэг болгон сүлжээний траффикийг тусгаарлах ба/эсвэл шифрлэлт, давуу механизмуудыг (802.1q, IPSec гэх мэт) мөн зааж өгсөн болно.
Архитектурын сонголт
Энэхүү гарын авлагад x86 архитектур болон 100% серверийн виртуалчлалаас өөр ямар ч сонголтыг авч үзэхгүй. Тиймээс тооцоолох дэд системийн архитектурын сонголт нь серверийн виртуалчлалын платформ, серверийн хэлбэр хүчин зүйл, серверийн тохиргооны ерөнхий шаардлагын сонголтоос хамаарна.
Сонголтын гол зүйл бол өгөгдөл боловсруулах, хадгалах, дамжуулах функцийг ялгах эсвэл нэгдмэл байдлаар сонгодог аргыг ашиглах нь гарцаагүй юм.
сонгодог архитектур Мэдээллийг хадгалах, дамжуулахад ухаалаг гадаад дэд системүүдийг ашиглахыг хамардаг бол серверүүд нь физик нөөцийн нийтлэг санд зөвхөн боловсруулалтын хүч болон RAM-ыг оруулдаг. Хэт их тохиолдолд серверүүд нь зөвхөн өөрийн дисктэй төдийгүй системийн танигчгүй бүрэн нэрээ нууцалдаг. Энэ тохиолдолд үйлдлийн систем эсвэл гипервизорыг суулгасан флаш зөөвөрлөгчөөс эсвэл гадаад өгөгдөл хадгалах системээс (SAN-аас ачаалах) ачаалдаг.
Сонгодог архитектурын хүрээнд ир ба тавиурын хоорондох сонголтыг дараахь зарчмууд дээр үндэслэн хийдэг.
— Зардал багатай (дунджаар тавиур дээр суурилуулсан серверүүд хямд байдаг);
- Тооцооллын нягтрал (иртний хувьд илүү өндөр);
- Эрчим хүчний зарцуулалт ба дулааны алдагдал (ир нь нэгжид илүү тодорхой нэгжтэй байдаг);
- Өргөтгөх, хянах боломжтой (их хэмжээний суурилуулалтанд ир нь ихэвчлэн бага хүчин чармайлт шаарддаг);
- Өргөтгөх картыг ашиглах (хотны хувьд маш хязгаарлагдмал сонголт).
Конвергент архитектур (мөн гэж нэрлэдэг хэт нийлсэн) нь өгөгдөл боловсруулах, хадгалах функцийг хослуулах явдал бөгөөд энэ нь локал серверийн дискийг ашиглахад хүргэдэг бөгөөд үүний үр дүнд сонгодог ир хэлбэрийн хүчин зүйлээс татгалзахад хүргэдэг. Нэгдсэн системүүдийн хувьд хэд хэдэн blade сервер болон локал дискийг нэг тохиолдолд нэгтгэсэн rack сервер эсвэл кластер системийг ашигладаг.
CPU/санах ой
Тохиргоог зөв тооцоолохын тулд та хүрээлэн буй орчин эсвэл бие даасан кластер бүрийн ачааллын төрлийг ойлгох хэрэгтэй.
CPU холбогдсон – процессорын хүчээр хязгаарлагдмал гүйцэтгэлтэй орчин. RAM нэмснээр гүйцэтгэлийн хувьд юу ч өөрчлөгдөхгүй (сервер бүрт VM-ийн тоо).
Санах ойд холбогдсон – RAM-аар хязгаарлагдсан орчин. Сервер дээрх илүү их RAM нь сервер дээр илүү олон VM ажиллуулах боломжийг олгодог.
GB / MHz (GB / pCPU) - энэ ачааллын RAM болон процессорын хүчин чадлын хэрэглээний дундаж харьцаа. Өгөгдсөн гүйцэтгэлд шаардагдах санах ойн хэмжээг тооцоолоход ашиглаж болно, мөн эсрэгээр.
Серверийн тохиргооны тооцоо
Эхлээд та бүх төрлийн ачааллыг тодорхойлж, өөр өөр тооцооллын сангуудыг өөр өөр кластерт нэгтгэх эсвэл хуваах шийдвэр гаргах хэрэгтэй.
Дараа нь тодорхойлсон кластер бүрийн хувьд GB / MHz харьцааг урьдчилан мэдэгдэж байсан ачаалал дээр тодорхойлно. Ачаалал нь урьдчилан мэдэгдээгүй ч процессорын эрчим хүчний ашиглалтын түвшний талаар тодорхой ойлголттой байгаа бол та стандарт vCPU:pCPU харьцааг ашиглан усан сангийн шаардлагыг биет болгон хувиргаж болно.
Кластер бүрийн хувьд vCPU сангийн шаардлагын нийлбэрийг коэффициентээр хуваана:
vCPUsum / vCPU:pCPU = pCPUsum – шаардлагатай физик нэгжийн тоо. цөм
pCPUsum / 1.25 = pCPUht – Hyper-Threading-д тохируулсан цөмийн тоо
190 цөм / 3.5 TB RAM бүхий кластерыг тооцоолох шаардлагатай гэж үзье. Үүний зэрэгцээ бид процессорын хүчин чадлын 50%, RAM-ийн 75% -ийн зорилтот ачааллыг хүлээн зөвшөөрдөг.
pCPU
190
CPU хэрэгсэл
50%
Мем
3500
Mem хэрэгсэл
75%
Сокет
Core
Srv/CPU
Srv Mem
Srv/Mem
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
Энэ тохиолдолд бид үргэлж хамгийн ойрын бүхэл тоо хүртэл бөөрөнхийлдөг (=ROUNDUP(A1;0)).
Хүснэгтээс харахад зорилтот үзүүлэлтүүдийн хувьд хэд хэдэн серверийн тохиргоог тэнцвэржүүлсэн нь тодорхой байна.
- 26 сервер 2*6c / 192 ГБ
- 19 сервер 2*10c / 256 ГБ
- 10 сервер 2*18c / 512 ГБ
Дараа нь эдгээр тохиргооны сонголтыг дулааны багц болон бэлэн хөргөлт, аль хэдийн ашигласан серверүүд эсвэл өртөг зэрэг нэмэлт хүчин зүйлд үндэслэн хийх ёстой.
Серверийн тохиргоог сонгох онцлог
Өргөн VM. Хэрэв өргөн VM-үүдийг (1 NUMA зангилаа ба түүнээс дээш хэмжээтэй харьцуулах боломжтой) байршуулах шаардлагатай бол боломжтой бол ийм VM-үүдийг NUMA зангилаа дотор байлгах тохиргоотой сервер сонгохыг зөвлөж байна. Олон тооны өргөн VM-үүдтэй бол кластерийн нөөц хуваагдах аюул байдаг бөгөөд энэ тохиолдолд өргөн VM-үүдийг аль болох нягт байрлуулах боломжийг олгодог серверүүдийг сонгодог.
Нэг бүтэлгүйтлийн домайн хэмжээ.
Серверийн хэмжээг сонгох нь нэг алдааны домэйныг багасгах зарчим дээр суурилдаг. Жишээ нь, сонгохдоо:
- 3 x 4*10c / 512 ГБ
- 6 x 2*10c / 256 ГБ
Бусад бүх зүйл ижил байх үед та хоёр дахь сонголтыг сонгох ёстой, учир нь нэг сервер ажиллахгүй байх үед (эсвэл засвар үйлчилгээ хийгдэж байх үед) кластерийн нөөцийн 33% биш, харин 17% алга болдог. Үүнтэй адилаар осолд өртсөн VM болон IS-ийн тоо хоёр дахин багассан.
Гүйцэтгэлд суурилсан сонгодог хадгалах системийг тооцоолох
Сонгодог хадгалалтын системүүд нь үйлдлийн кэшийн нөлөөлөл, үйл ажиллагааг оновчтой болгохоос бусад тохиолдолд хамгийн муу хувилбарыг ашиглан үргэлж тооцдог.
Гүйцэтгэлийн үндсэн үзүүлэлтүүдийн хувьд бид механик гүйцэтгэлийг дискнээс (IOPSdisk) авдаг.
– 7.2к – 75 IOPS
– 10к – 125 IOPS
– 15к – 175 IOPS
Дараа нь дискний сан дахь дискний тоог дараах томъёогоор тооцоолно. = TotalIOPS * ( RW + (1 –RW) * RAIDPen) / IOPSdisk. Хаана:
- Нийт IOPS – дискний сангаас IOPS-д шаардагдах нийт гүйцэтгэл
- RW – унших үйлдлийн хувь
- RAIDpen – Сонгосон RAID түвшний хувьд RAID торгууль
Төхөөрөмжийн RAID болон RAID торгуулийн талаар эндээс уншина уу - и и
Үүссэн дискний тоон дээр үндэслэн хадгалах багтаамжийн шаардлагад нийцсэн боломжит хувилбарууд, тэр дундаа олон түвшний санах ойтой сонголтуудыг тооцдог.
Хадгалах давхарга болгон SSD ашигладаг системийн тооцоог тусад нь авч үздэг.
Flash кэш ашиглан тооцоолох системийн онцлог
Flash кэш – флаш санах ойг хоёр дахь түвшний кэш болгон ашиглах бүх өмчийн технологийн нийтлэг нэр. Флэш кэш ашиглах үед хадгалах системийг ихэвчлэн соронзон дискнээс тогтмол ачааллыг хангахаар тооцдог бол дээд цэг нь кэшээр үйлчилдэг.
Энэ тохиолдолд ачааллын профайл, хадгалах багтаамжийн блок руу нэвтрэх эрхийг нутагшуулах түвшинг ойлгох шаардлагатай. Flash кэш нь өндөр нутагшуулсан асуулга бүхий ажлын ачаалалд зориулсан технологи бөгөөд жигд ачаалалтай (аналитик систем гэх мэт) эзлэхүүнд бараг тохиромжгүй.
Доод/дунд түвшний эрлийз системийн тооцоо
Доод болон дунд ангийн эрлийз систем нь хуваарийн дагуу түвшний хооронд шилжих өгөгдөл бүхий олон түвшний хадгалалтыг ашигладаг. Үүний зэрэгцээ шилдэг загваруудад зориулсан олон түвшний хадгалах блокийн хэмжээ 256 МБ байна. Эдгээр боломжууд нь олон хүн буруугаар итгэдэг шиг шаталсан хадгалах технологийг бүтээмжийг нэмэгдүүлэх технологи гэж үзэх боломжийг бидэнд олгодоггүй. Бага ба дунд зэрэглэлийн систем дэх олон түвшний хадгалалт нь ачааллын жигд бус байдал бүхий системүүдийн хадгалах зардлыг оновчтой болгох технологи юм.
Шаталсан хадгалалтын хувьд дээд түвшний гүйцэтгэлийг эхлээд тооцдог бол доод шатлал нь зөвхөн дутуу хадгалах багтаамжид нөлөөлдөг гэж үздэг. Гибрид олон шатлалт системийн хувьд доод түвшнээс гэнэт халсан өгөгдлийн гүйцэтгэлийн бууралтыг нөхөхийн тулд олон шатлалт санд зориулсан флаш кэш технологийг заавал ашиглах ёстой.
шаталсан дискний санд SSD ашиглах
Олон түвшний дискний санд SSD ашиглах нь тухайн үйлдвэрлэгчийн флаш кэш алгоритмын тодорхой хэрэгжилтээс хамаарч өөр өөр байдаг.
SSD түвшний дискний санд зориулсан хадгалах бодлогын ерөнхий практик нь эхлээд SSD юм.
Зөвхөн унших Flash кэш. Зөвхөн уншигдах боломжтой флаш кэшийн хувьд SSD дээрх хадгалах давхарга нь кэшээс үл хамааран бичилтийг ихээхэн нутагшуулах боломжтой.
Flash кэш унших/бичих. Флэш кэшийн хувьд бичих кэшийн хэмжээг эхлээд кэшийн дээд хэмжээнд тохируулдаг бөгөөд зөвхөн кэшийн хэмжээ нь орон нутгийн ажлын ачааллыг бүхэлд нь хангахад хангалтгүй үед л SSD хадгалах түвшин гарч ирнэ.
SSD болон кэшийн гүйцэтгэлийн тооцооллыг үйлдвэрлэгчийн зөвлөмжид үндэслэн хийдэг боловч хамгийн муу тохиолдолд үргэлж хийдэг.
Эх сурвалж: www.habr.com