NetApp Engineer

Mawalang ang pagkawala sa parehong presence at mga post. Ito ay isang pison-ang naninirahan malapit sa baybayin nakaraang taon na may personal na pinsala at trabaho iskedyul na-out sa flat, kaya ako ay may maliit na oras o pagbubuyo sa blog o ipakita ang aking mukha sa paligid ng mga komunidad. Aking pasensiya, at Ako ay tinutukoy upang basagin ang ugali na ito at bumalik sa mga bagay-bagay sa sandaling muli! Ngunit sapat ng magdaldalan, makakuha ng sa sa ang writings ...

Ito ay hindi isang bagay na ko makita ang masyadong madalas, ngunit kapag ko, ito ay kagiliw-giliw na upang makita ang stats ng makipag-usap para sa kanilang sarili. Ako ay may isang customer na may isang scripted deployment ng kanilang mga ari-arian ng NetApp ng ilang taon na ang nakaraan, at hindi ito ay dinisenyo o na inihatid may masyadong maraming pag-aalaga o pansin (isang bagay na nais ko upang talakayin ang isa pang araw). Mayroon silang isang VMware estate sa SQL, Exchange at iba pang mga bagay. Lahat ng ito ay tumatakbo sa isang total ng higit sa 100 15k FC spindles. Ito ay hindi isang malaking estate sa paghahambing sa iba pang mga site, kaya ako intrigued sa kung bakit mayroon silang tulad ng mga isyu sa pagganap.

Ngayon kapag tumakbo sa pamamagitan ng "sysstat-u", maaari mong makita na ang filer mismo ay paggawa ng masyadong maliit, masyadong maligaya pagkuha sa sa kung ano ang dapat gawin. Ngunit disk ay pagpindot 100% lubos madalas. Kaagad na ito ay nagpapakita ng isang problema sa disk. Kailangan nila ng karagdagang spindles, malinaw?

Ang una ay isang liblib ng spindles. Mayroon sila ng pangalawang pinagsama-samang sa partner controller na lamang ay may volume na pagsubok. Ako nakakakuha ng pahintulot upang tanggalin ito at mainit, ako muling magtalaga ng mga ito sa iba pang mga controller at palawakin ang mga umiiral na pinagsama-samang. Ito doubles ang suliran bilang, ngunit ang alam ko hindi ito ay pagpunta sa gawin para sa umiiral na pagganap (sa na ang data ay hindi awtomatikong mamigay na muli mismo!).

Kung tumakbo ko sa pamamagitan ng "disk istatistika ipakita: *: disk_busy" ko makita ang isang bagay na medyo halata. May isang solong disk sa buong sistema na pagpindot 100%, ang natitira ay hindi. May isang grupo ng iba pang mga disk (10), na tumatakbo ng 50-60%, at pagkatapos ay ang natitirang disk-gris layo sa paligid ng 20-30%. Kaya kung ano ang nangyari dito? NetApp teknolohiya ay dapat na maiwasan ang anumang form ng mainit suliran sa sistema.

Ang aking teorya ito. Ang filer ay racked at isinalansan ng kahon, ngunit pinagsama-samang ay hindi lumago (3 disk pinagsama-samang, 1 data, 2 pagkakapareho). Ang ang imbakan ilang ay provisioned at data mailipat. Sila tumakbo ng puwang, upang lumago ang pinagsamang (ng kaunti), pagkatapos ay kinopya ang ilang mas maraming data papunta sa disk. Matapos ang lahat ng ito, pagkatapos sila ay nagdagdag ng pahinga ng disk. Ngayon dahil ang data ay hindi awtomatikong muling maglaan sa mabilisang, ang anumang data na nananatiling hindi nagbabago (bilang ang mangyayari sa VM System disk, lumang Exchange email, at lumang Data Warehousing data), at pagkatapos pa rin sila Sab sa ang orihinal na spindles o kahit na suliran bilang kapag sila ay unang-install.

Kaya ngayon Naghahanap ako inaabangan ang panahon na ang katapusan ng linggo. Kami ay mag-upgrade ito sa Data ONTAP 7.3.2 at maaari ba akong magpatakbo ng ilang reallocation scan sa buong sistema na hindi nakakaapekto sa paggamit ng puwang ng snapshot (malaking bonus, salamat NetApp!). Ako hoping na ito ay alisin ang mainit na isyu suliran. Mayroon akong ilang mga bago stats, at kukunin ko na hilahin ang ilang mga pagkatapos stats susunod na linggo. Kukunin ko i-update ang post na ito nang naaayon.

Aral mula sa kuwento? I-setup ang iyong imbakan sistema ay ganap at lubusan bago ka magsimulang pagkahagis data ito. Huwag maging abala tungkol sa gamit ang iyong bagong laruan imbakan at itapon ang mga data ito kaagad. Nakita ko ang itaas na sitwasyon sa ilang mga okasyon ngayon, at bago ONTAP 7.3, ito ay isang sakit upang ayusin.

Mabilis na snapshot ng ang output ng stats. Ilagay sa isip na sa isang cluster na ito ay ipakita ang lahat ng mga disk, kaya lahat ng mga stats ng disk ay ganap na may-katuturan. Ang mga abala na disk dito lamang ay hindi magdagdag ng hanggang sa aktwal na bilang ng mga disk sa sistema, at maaari mong malinaw na makita ang isa abala disk.

> Sysstat-u 1
CPU Kabuuang Net kB / s Disk kB / s Tape kB / s Cache Cache CP CP Disk
ops / s sa out basahin ang sumulat basahin isulat ang edad hit Ty util oras
11% 3220 6942 3270 4232 0 0 0 12 95% 0% - 60%
11% 2898 7385 4030 4892 0 0 0 11 94% 0% - 69%
9% 3547 1820 3496 3920 24 0 0 11 93% 0% - 89%
7% 2329 1160 3048 3892 0 0 0 11 93% 0% - 81%
10% 3173 2055 4851 4644 8 0 0 11 93% 0% - 67%
9% 2491 1860 4547 4568 24 0 0 11 91% 0% - 98%
9% 2523 2960 4404 5372 0 0 0 11 90% 0% - 89%
14% 5136 8173 4465 3352 0 0 0 11 95% 0% - 81%

> Stats disk ng palabas: *: disk_busy
... Gupitin ...

... Gupitin ...