Kamusta kayong lahat! Sa artikulong ito, nagbubukas ang AERODISK ng blog sa Habré. Hurray, mga kasama!
Ang mga nakaraang artikulo sa Habré ay tinalakay ang mga tanong tungkol sa arkitektura at pangunahing pagsasaayos ng mga sistema ng imbakan. Sa artikulong ito ay isasaalang-alang namin ang isang tanong na hindi pa nasasakupan dati, ngunit madalas itanong - tungkol sa pagpapahintulot sa kasalanan ng mga sistema ng imbakan ng AERODISK ENGINE. Gagawin ng aming team ang lahat para matiyak na hihinto sa paggana ang AERODISK storage system, i.e. sirain ito.
Nagkataon na ang mga artikulo tungkol sa kasaysayan ng aming kumpanya, tungkol sa aming mga produkto, pati na rin ang isang halimbawa ng matagumpay na pagpapatupad ay nakabitin na sa Habré, kung saan Maraming salamat sa aming mga kasosyo - mga kumpanya ng TS Solution at Softline.
Samakatuwid, hindi ako magsasanay ng mga kasanayan sa pamamahala ng copy-paste dito, ngunit magbibigay lamang ng mga link sa mga orihinal ng mga artikulong ito:
Gusto ko ring magbahagi ng magandang balita. Ngunit magsisimula ako, siyempre, sa problema. Kami, bilang isang batang vendor, bukod sa iba pang mga gastos, ay patuloy na nahaharap sa katotohanang maraming mga inhinyero at administrador ang hindi alam kung paano maayos na patakbuhin ang aming sistema ng imbakan.
Malinaw na ang pamamahala sa karamihan ng mga sistema ng imbakan ay mukhang halos pareho mula sa pananaw ng isang administrator, ngunit ang bawat tagagawa ay may sariling mga katangian. At hindi tayo exception dito.
Samakatuwid, upang gawing simple ang gawain ng pagsasanay sa mga espesyalista sa IT, nagpasya kaming italaga ang taong ito sa libreng edukasyon. Upang gawin ito, sa maraming malalaking lungsod ng Russia, binubuksan namin ang isang network ng AERODISK Competence Centers, kung saan ang sinumang interesadong teknikal na espesyalista ay maaaring kumuha ng kursong walang bayad at makatanggap ng sertipiko sa pangangasiwa ng mga sistema ng imbakan ng AERODISK ENGINE.
Sa bawat Competence Center, mag-i-install kami ng ganap na demo stand mula sa AERODISK storage system at isang pisikal na server, kung saan magsasagawa ang aming guro ng face-to-face na pagsasanay. Ipa-publish namin ang iskedyul ng trabaho ng Competence Centers sa kanilang hitsura, ngunit nagbukas na kami ng isang sentro sa Nizhny Novgorod at ang lungsod ng Krasnodar ay susunod. Maaari kang mag-sign up para sa pagsasanay gamit ang mga link sa ibaba. Narito ang kasalukuyang kilalang impormasyon tungkol sa mga lungsod at petsa:
- Nizhny Novgorod (NABUKAS NA – maaari kang mag-sign up dito );
Hanggang Abril 16, 2019, maaari kang bumisita sa sentro sa anumang oras ng trabaho, at sa Abril 16, 2019, isang malaking kurso sa pagsasanay ang isasaayos. - Krasnodar (OPENING SOON - maaari kang mag-sign up dito );
Mula Abril 9 hanggang Abril 25, 2019, maaari mong bisitahin ang sentro sa anumang oras ng trabaho, at sa Abril 25, 2019, isang malaking kurso sa pagsasanay ang isasaayos. - Yekaterinburg (Malapit nang magbukas, sundin ang impormasyon sa aming website o sa Habré);
Mayo-Hunyo 2019. - Novosibirsk (sundin ang impormasyon sa aming website o sa Habré);
Oktubre 2019. - Krasnoyarsk (sundin ang impormasyon sa aming website o sa Habré);
Nobyembre 2019.
At, siyempre, kung ang Moscow ay hindi malayo sa iyo, sa anumang oras maaari mong bisitahin ang aming opisina sa Moscow at sumailalim sa katulad na pagsasanay.
Lahat. Tapos na tayo sa marketing, let's move on to technology!
Sa Habré, regular kaming mag-publish ng mga teknikal na artikulo tungkol sa aming mga produkto, mga pagsubok sa pag-load, paghahambing, mga tampok ng paggamit at mga kagiliw-giliw na pagpapatupad.
Mga pagsubok sa pag-crash ng sistema ng imbakan ng AERODISK ENGINE N2, pagsubok ng lakas
WARNING! Matapos basahin ang artikulo, maaari mong sabihin: mabuti, siyempre, susuriin ng vendor ang kanyang sarili upang ang lahat ay gumagana "na may isang putok," mga kondisyon ng greenhouse, atbp. Sasagot ako: walang ganyan! Hindi tulad ng aming mga dayuhang kakumpitensya, kami ay matatagpuan dito, malapit sa iyo, at maaari kang palaging pumunta sa amin (sa Moscow o anumang Central Committee) at subukan ang aming storage system sa anumang paraan. Kaya, hindi gaanong makatuwiran para sa amin na ayusin ang mga resulta sa isang perpektong larawan ng mundo, dahil Napakadali naming suriin. Para sa mga tamad na pumunta at walang oras, maaari naming ayusin ang malayuang pagsubok. Mayroon kaming espesyal na lab para dito. Makipag-ugnayan sa amin.
ACHTUNG-2! Ang pagsusulit na ito ay hindi isang pagsubok sa pagkarga, dahil dito lang namin inaalala ang fault tolerance. Sa loob ng ilang linggo, maghahanda kami ng mas makapangyarihang stand at magsasagawa ng load testing ng storage system, na mag-publish ng mga resulta dito (nga pala, tinatanggap ang mga kahilingan para sa mga pagsubok).
Kaya, buksan na natin ito.
Test stand
Ang aming stand ay binubuo ng sumusunod na hardware:
- 1 x Aerodisk Engine N2 storage system (2 controller, 64GB cache, 8xFC port 8Gb/s, 4xEthernet port 10Gb/s SFP+, 4xEthernet port 1Gb/s); Ang mga sumusunod na disk ay naka-install sa sistema ng imbakan:
- 4 x SAS SSD disk 900 GB;
- 12 x SAS 10k disk na 1,2 TB;
- 1 x Pisikal na server na may Windows Server 2016 (2xXeon E5 2667 v3, 96GB RAM, 2xFC port 8Gb/s, 2xEthernet port 10Gb/s SFP+);
- 2 x SAN 8G switch;
- 2 x LAN 10G switch;
Ikinonekta namin ang server sa storage system sa pamamagitan ng mga switch sa pamamagitan ng parehong FC at 10G Ethernet. Nasa ibaba ang stand diagram.
Ang mga sangkap na kailangan namin, tulad ng MPIO at iSCSI initiator, ay naka-install sa Windows Server.
Naka-configure ang mga zone sa mga switch ng FC, naka-configure ang mga kaukulang VLAN sa mga switch ng LAN, at naka-install ang MTU 9000 sa mga port ng storage, switch, at host (kung paano gawin ang lahat ng ito ay inilarawan sa aming dokumentasyon, kaya hindi namin ilalarawan ang prosesong ito dito).
Pamamaraan ng Pagsubok
Ang plano ng pagsubok sa pag-crash ay ang sumusunod:
- Sinusuri ang pagkabigo ng FC at Ethernet port.
- Pagsusuri ng power failure.
- Pagsusuri ng pagkabigo ng controller.
- Sinusuri ang disk failure sa isang grupo/pool.
Ang lahat ng mga pagsubok ay isasagawa sa ilalim ng sintetikong mga kondisyon ng pagkarga, na bubuuin namin ng programang IOMETER. Kaayon, magsasagawa kami ng parehong mga pagsubok, ngunit sa ilalim ng mga kondisyon ng pagkopya ng malalaking file sa sistema ng imbakan.
Ang config ng IOmeter ay ang mga sumusunod:
- Basahin/Isulat – 70/30
- Block – 128k (napagpasyahan naming hugasan ang mga storage system sa malalaking bloke)
- Bilang ng mga thread – 128 (na halos kapareho sa productive load)
- Buong Random
- Bilang ng mga Manggagawa – 4 (2 para sa FC, 2 para sa iSCSI)
Ang pagsusulit ay may mga sumusunod na layunin:
- Siguraduhin na ang synthetic na pag-load at proseso ng pagkopya ay hindi makakaabala o magdudulot ng mga error sa ilalim ng iba't ibang mga senaryo ng pagkabigo.
- Siguraduhin na ang proseso ng paglipat ng mga port, controllers, atbp. ay sapat na awtomatiko at hindi nangangailangan ng mga aksyon ng administrator kung sakaling may mga pagkabigo (iyon ay, sa panahon ng mga failover, hindi namin pinag-uusapan ang mga failback, siyempre).
- Siguraduhin na ang impormasyon sa mga log ay ipinapakita nang tama.
Paghahanda ng host at storage system
Na-configure namin ang block access sa storage system gamit ang FC at Ethernet port (FC at iSCSI, ayon sa pagkakabanggit). Ang mga lalaki mula sa TS Solution ay inilarawan nang detalyado kung paano gawin ito sa isang nakaraang artikulo (). At, siyempre, walang nagkansela ng mga manwal at kurso.
Nag-set up kami ng hybrid na grupo gamit ang lahat ng drive na mayroon kami. 2 SSD disk ang idinagdag sa cache, 2 SSD disk ang idinagdag bilang karagdagang storage tier (Online-tier). Pinag-grupo namin ang 12 SAS10k drive sa RAID-60P (triple parity) upang suriin ang pagkabigo ng tatlong drive sa grupo nang sabay-sabay. Isang disk ang naiwan para sa autoreplacement.
Ikinonekta namin ang dalawang LUN (isa sa pamamagitan ng FC, isa sa pamamagitan ng iSCSI).
Ang may-ari ng parehong LUN ay ang Engine-0 controller
Simulan na natin ang pagsubok
Pinagana namin ang IOMETER gamit ang config sa itaas.
Nag-record kami ng throughput na 1.8 GB/s at latency na 3 millisecond. Walang mga error (Kabuuang Bilang ng Error).
Kasabay nito, mula sa lokal na drive na "C" ng aming host, parallel naming simulan ang pagkopya ng dalawang malalaking 100GB na file sa FC at iSCSI storage LUNs (drive E at G sa Windows), gamit ang iba pang mga interface.
Sa itaas ay ang proseso ng pagkopya sa LUN FC, sa ibaba sa iSCSI.
Pagsubok #1: Hindi pagpapagana ng mga I/O port
Lumapit kami sa sistema ng imbakan mula sa likod))) at sa isang bahagyang paggalaw ng kamay ay hinuhugot namin ang lahat ng mga kable ng FC at Ethernet 10G mula sa controller ng Engine-0. Para bang may isang babaeng naglilinis na may dalang mop at nagpasyang hugasan ang sahig kung saan nakahiga ang uhog at ang mga kable ay nakahiga (ibig sabihin, gumagana pa rin ang controller, ngunit patay na ang mga I/O port).
Tingnan natin ang IOMETER at pagkopya ng mga file. Ang throughput ay bumaba sa 0,5 GB/s, ngunit mabilis na bumalik sa dati nitong antas (sa humigit-kumulang 4-5 segundo). Walang mga error.
Ang pagkopya ng mga file ay hindi tumigil, mayroong pagbaba sa bilis, ngunit hindi ito kritikal (mula sa 840 MB/s ay bumaba ito sa 720 MB/s). Hindi huminto ang pagkopya.
Tinitingnan namin ang mga log ng storage system at nakikita ang isang mensahe tungkol sa hindi pagkakaroon ng mga port at ang awtomatikong relokasyon ng grupo.
Sinasabi rin sa amin ng panel ng impormasyon na ang lahat ay hindi masyadong maganda sa mga port ng FC.
Ang sistema ng imbakan ay nakaligtas sa pagkabigo ng mga I/O port matagumpay.
Pagsubok Blg. 2. Hindi pagpapagana ng storage controller
Halos kaagad (pagkatapos na maisaksak ang mga cable pabalik sa storage system) nagpasya kaming tapusin ang storage system sa pamamagitan ng paghila ng controller palabas ng chassis.
Muli naming nilapitan ang sistema ng imbakan mula sa likuran (nagustuhan namin ito))) at sa pagkakataong ito ay hinila namin ang controller ng Engine-1, na sa sandaling ito ay ang may-ari ng RDG (kung saan lumipat ang grupo).
Ang sitwasyon sa IOmeter ay ang mga sumusunod. Huminto ang I/O nang mga 5 segundo. Hindi naiipon ang mga error.
Pagkalipas ng 5 segundo, nagpatuloy ang I/O na may halos parehong throughput, ngunit may mga latency na 35 millisecond (naitama ang mga latency pagkatapos ng humigit-kumulang ilang minuto). Tulad ng makikita mula sa mga screenshot, ang kabuuang halaga ng bilang ng error ay 0, ibig sabihin, walang mga error sa pagsusulat o pagbabasa.
Tingnan natin ang pagkopya ng aming mga file. Tulad ng nakikita mo, hindi ito naantala, nagkaroon ng bahagyang pagbaba sa pagganap, ngunit sa pangkalahatan ang lahat ay bumalik sa parehong ~ 800 MB/s.
Pumunta kami sa sistema ng imbakan at nakakita ng sumpa sa panel ng impormasyon na hindi available ang Engine-1 controller (siyempre, pinatay namin ito).
Nakikita rin namin ang isang katulad na entry sa mga log.
Ang storage controller ay nakaligtas din sa pagkabigo matagumpay.
Pagsubok No. 3: Pagdiskonekta sa power supply.
Kung sakali, nagsimula kaming muling kumopya ng mga file, ngunit hindi huminto sa IOMETER.
Hinihila namin ang power supply unit.
Ang isa pang alerto ay idinagdag sa sistema ng imbakan sa panel ng impormasyon.
Gayundin sa menu ng mga sensor makikita natin na ang mga sensor na nauugnay sa na-pull out na supply ng kuryente ay naging pula.
Patuloy na gumagana ang storage system. Ang pagkabigo ng power supply unit ay hindi sa anumang paraan ay nakakaapekto sa pagpapatakbo ng sistema ng imbakan; mula sa punto ng view ng host, ang bilis ng kopya at mga tagapagpahiwatig ng IOMETER ay nanatiling hindi nagbabago.
Lumipas ang pagsubok sa power failure matagumpay.
Bago ang huling pagsubok, napagpasyahan naming buhayin ng kaunti ang storage system, ibalik ang controller at power supply unit, at ayusin din ang mga cable, na masayang ipinaalam sa amin ng storage system na may mga berdeng icon sa health panel nito. .
Pagsubok No. 4. Pagkabigo ng tatlong disk sa isang grupo
Bago ang pagsusulit na ito, nagsagawa kami ng karagdagang hakbang sa paghahanda. Ang katotohanan ay ang sistema ng imbakan ng ENGINE ay nagbibigay ng isang napaka-kapaki-pakinabang na bagay - iba't ibang mga patakaran sa muling pagtatayo. Sumulat ang TS Solution tungkol sa tampok na ito nang mas maaga, ngunit alalahanin natin ang kakanyahan nito. Maaaring tukuyin ng administrator ng storage ang priyoridad para sa paglalaan ng mapagkukunan sa panahon ng muling pagtatayo. Alinman sa direksyon ng pagganap ng I/O, iyon ay, ang muling pagbuo ay mas matagal, ngunit walang performance drawdown. O sa direksyon ng muling pagtatayo ng bilis, ngunit ang pagiging produktibo ay mababawasan. O isang balanseng opsyon. Dahil ang pagganap ng storage sa panahon ng muling pagbuo ng disk group ay palaging nakakasakit ng ulo ng admin, susubukan namin ang isang patakaran na may bias sa pagganap ng I/O at sa kapinsalaan ng bilis ng muling pagbuo.
Ngayon tingnan natin kung may pagkabigo sa disk. Pinapagana din namin ang pag-record sa mga LUN (mga file at IOMETER). Dahil mayroon kaming isang pangkat na may triple parity (RAID-60P), nangangahulugan ito na ang system ay dapat makatiis sa pagkabigo ng tatlong mga disk, at pagkatapos ng pagkabigo, ang awtomatikong pagpapalit ay dapat gumana, ang isang disk ay dapat pumalit sa isa sa mga nabigo. sa RDG, at dapat magsimula dito ang muling pagtatayo.
Magsimula. Una, sa pamamagitan ng interface ng imbakan, i-highlight natin ang mga disk na gusto nating i-pull out (upang hindi makaligtaan at hilahin ang autochange disk).
Sinusuri namin ang indikasyon sa hardware. Ang lahat ay OK, nakikita namin ang tatlong naka-highlight na mga disk.
At inilabas namin ang tatlong disk na ito.
Tingnan natin kung ano ang nasa host. At doon... walang espesyal na nangyari.
Ang mga tagapagpahiwatig ng pagkopya (mas mataas ang mga ito kaysa sa simula, dahil ang cache ay nagpainit) at ang IOMETER ay hindi gaanong nagbabago kapag inaalis ang mga disk at sinimulan ang muling pagtatayo (sa loob ng 5-10%).
Tingnan natin kung ano ang nasa sistema ng imbakan.
Sa status ng grupo, nakita natin na nagsimula na ang proseso ng restructuring at malapit na itong matapos.
Sa balangkas ng RDG makikita mo na ang 2 disk ay nasa pulang katayuan, at ang isa ay napalitan na. Ang autoreplacement disk ay wala na doon; pinalitan nito ang ika-3 nabigong disk. Ang muling pagtatayo ay tumagal ng ilang minuto, ang pagsusulat ng mga file kapag nabigo ang 3 disk ay hindi nagambala, at ang pagganap ng I/O ay hindi masyadong nagbago.
Tiyak na pumasa ang pagsubok sa disk failure matagumpay.
Konklusyon
Sa puntong ito, nagpasya kaming itigil ang karahasan laban sa mga storage system. Ibuod natin:
- Pagsusuri sa pagkabigo ng FC port - matagumpay
- Pagsusuri sa pagkabigo ng Ethernet port - matagumpay
- Pagsusuri ng pagkabigo ng controller - matagumpay
- Power Failure Test - Matagumpay
- Sinusuri ang pagkabigo sa disk sa grouppool - matagumpay
Wala sa mga pagkabigo ang huminto sa pagre-record o nagdulot ng mga error sa synthetic load; siyempre, nagkaroon ng performance hit (at alam namin kung paano ito malalampasan, na gagawin namin sa lalong madaling panahon), ngunit dahil sa mga segundo na ito, ito ay lubos na katanggap-tanggap. Konklusyon: ang pagpapahintulot sa kasalanan ng lahat ng mga bahagi ng sistema ng imbakan ng AERODISK ay nagtrabaho sa antas, walang mga punto ng pagkabigo.
Malinaw, sa isang artikulo ay hindi namin masusubok ang lahat ng mga senaryo ng pagkabigo, ngunit sinubukan naming saklawin ang mga pinakasikat. Samakatuwid, mangyaring ipadala ang iyong mga komento, mungkahi para sa hinaharap na mga publikasyon at, siyempre, sapat na pagpuna. Natutuwa kaming pag-usapan (o mas mabuti pa, pumunta sa pagsasanay, doblehin ko ang iskedyul kung sakali)! Hanggang sa mga bagong pagsubok!
- Nizhny Novgorod (NABUKAS NA – maaari kang mag-sign up dito );
Hanggang Abril 16, 2019, maaari kang bumisita sa sentro sa anumang oras ng trabaho, at sa Abril 16, 2019, isang malaking kurso sa pagsasanay ang isasaayos. - Krasnodar (OPENING SOON - maaari kang mag-sign up dito );
Mula Abril 9 hanggang Abril 25, 2019, maaari mong bisitahin ang sentro sa anumang oras ng trabaho, at sa Abril 25, 2019, isang malaking kurso sa pagsasanay ang isasaayos. - Yekaterinburg (Malapit nang magbukas, sundin ang impormasyon sa aming website o sa Habré);
Mayo-Hunyo 2019. - Novosibirsk (sundin ang impormasyon sa aming website o sa Habré);
Oktubre 2019. - Krasnoyarsk (sundin ang impormasyon sa aming website o sa Habré);
Nobyembre 2019.
Pinagmulan: www.habr.com