Մեր մեկում Ձեռնարկությունում Zimbra Collabortion Suite-ի ներդրման ժամանակ նվիրված ենթակառուցվածքի պլանավորմանը, ասվեց, որ այս լուծման գործարկման հիմնական սահմանափակումը փոստի պահեստներում սկավառակի սարքերի մուտքի/ելք արագությունն է: Իրոք, այն ժամանակ, երբ ձեռնարկության մի քանի հարյուր աշխատակիցներ միաժամանակ մուտք են գործում փոստի նույն պահեստը, կոշտ սկավառակներից տեղեկատվություն գրելու և կարդալու համար ալիքի լայնությունը կարող է բավարար չլինել ծառայության պատասխանատու աշխատանքի համար: Եվ եթե Zimbra-ի փոքր տեղակայանքների համար դա առանձնահատուկ խնդիր չի լինի, ապա խոշոր ձեռնարկությունների և SaaS պրովայդերների դեպքում այս ամենը կարող է հանգեցնել չպատասխանելու էլ. SLA-ների. Այդ իսկ պատճառով, Zimbra-ի լայնածավալ կայանքները նախագծելիս և շահագործելիս պետք է հատուկ ուշադրություն դարձնել փոստի պահեստում կոշտ սկավառակների աշխատանքի օպտիմալացմանը: Դիտարկենք երկու դեպք և փորձենք պարզել, թե սկավառակի պահեստավորման բեռը օպտիմալացնելու ինչ մեթոդներ կարող են կիրառվել դրանցից յուրաքանչյուրում:
1. Օպտիմալացում Zimbra-ի լայնածավալ տեղադրման նախագծման ժամանակ
Zimbra-ի բարձր բեռնվածության տեղադրման նախագծման փուլում ադմինիստրատորը պետք է ընտրություն կատարի, թե որ պահեստային համակարգն օգտագործի: Այս հարցում որոշելու համար դուք պետք է իմանաք, որ կոշտ սկավառակների հիմնական ծանրաբեռնվածությունը գալիս է MariaDB DBMS-ից, որը ներառված է Zimbra Collaboration Suite-ում, Apache Lucene որոնողական համակարգից և բլբի պահեստից: Այդ իսկ պատճառով այս ծրագրային արտադրանքները բարձր ծանրաբեռնվածության պայմաններում գործարկելու համար անհրաժեշտ է օգտագործել գերարագ և հուսալի սարքավորումներ:
Սովորական պայմաններում Zimbra-ն կարող է տեղադրվել ինչպես կոշտ սկավառակների RAID-ի, այնպես էլ NFS արձանագրության միջոցով միացված պահեստում: Շատ փոքր տեղադրումների համար դուք կարող եք տեղադրել Zimbra սովորական SATA սկավառակի վրա: Այնուամենայնիվ, խոշոր կայանքների համատեքստում այս բոլոր տեխնոլոգիաները ցույց են տալիս տարբեր թերություններ՝ ձայնագրման նվազման արագության կամ ցածր հուսալիության տեսքով, ինչը անընդունելի է ոչ խոշոր ձեռնարկությունների, ոչ էլ, հատկապես, SaaS մատակարարների համար:
Ահա թե ինչու Zimbra-ի լայնածավալ ենթակառուցվածքներում լավագույնն է օգտագործել SAN-ը: Հենց այս տեխնոլոգիան է ներկայումս ունակ ապահովելու ամենամեծ թողունակությունը պահեստավորման սարքերի համար և միևնույն ժամանակ, մեծ քանակությամբ քեշ միացնելու ունակության շնորհիվ, դրա օգտագործումը գործնականում որևէ էական ռիսկ չի ներկայացնում ձեռնարկության համար: Լավ գաղափար է օգտագործել NVRAM-ը, որն օգտագործվում է բազմաթիվ SAN-ներում՝ գրելու ժամանակ արագացնելու համար: Բայց ավելի լավ է անջատել ձայնագրված տվյալների քեշավորումը հենց սկավառակների վրա, քանի որ դա կարող է հանգեցնել լրատվամիջոցների անուղղելի վնասների և տվյալների կորստի, եթե հոսանքի հետ կապված խնդիրներ առաջանան:
Ինչ վերաբերում է ֆայլային համակարգի ընտրությանը, ապա լավագույն ընտրությունը կլինի ստանդարտ Linux Ext3/Ext4-ի օգտագործումը: Ֆայլային համակարգի հետ կապված հիմնական նրբությունն այն է, որ այն պետք է տեղադրվի պարամետրով - Նոատին. Այս տարբերակը կանջատի ֆայլերի վերջին մուտքի ժամանակը գրանցելու գործառույթը, ինչը նշանակում է, որ այն զգալիորեն կնվազեցնի ընթերցանության և գրելու բեռը: Ընդհանուր առմամբ, Zimbra-ի համար ext3 կամ ext4 ֆայլային համակարգ ստեղծելիս պետք է օգտագործեք հետևյալ օգտակար պարամետրերը. mke2fs:
-j — Ֆայլային համակարգի ամսագիր ստեղծելու համար Ստեղծեք ֆայլային համակարգը ext3/ext4 ամսագրով:
-Լ ԱՆՈՒՆ - Հատորի անուն ստեղծելու համար այն օգտագործելու համար /etc/fstab-ում
-O dir_index - Հաշված որոնման ծառ օգտագործելու համար ֆայլերի որոնումները մեծ գրացուցակներում արագացնելու համար
-մ 2 — Խոշոր ֆայլային համակարգերում ծավալի 2%-ը վերապահել արմատային գրացուցակի համար
-J չափ=400 — Մեծ ամսագիր ստեղծելու համար
-բ 4096 — Բլոկի չափը բայթերով որոշելու համար
-ի 10240 - Հաղորդագրությունների պահպանման համար այս պարամետրը պետք է համապատասխանի հաղորդագրության միջին չափին: Դուք պետք է մեծ ուշադրություն դարձնեք այս պարամետրին, քանի որ դրա արժեքը հետագայում չի կարող փոխվել:
Խորհուրդ է տրվում նաև միացնել dirsync բլբի պահպանման, Lucene որոնման մետատվյալների պահպանման և MTA հերթերի պահպանման համար: Դա պետք է արվի, քանի որ Zimbra-ն սովորաբար օգտագործում է կոմունալ ծրագիրը fsync սկավառակի վրա տվյալների հետ բլբի երաշխավորված գրելու համար: Այնուամենայնիվ, երբ Zimbra փոստի խանութը կամ MTA-ն նոր ֆայլեր է ստեղծում հաղորդագրությունների առաքման ժամանակ, անհրաժեշտ է դառնում սկավառակի վրա գրել համապատասխան թղթապանակներում տեղի ունեցող փոփոխությունները: Ահա թե ինչու, նույնիսկ եթե ֆայլն արդեն գրվել է սկավառակի վրա՝ օգտագործելով fsync, գրացուցակում դրա ավելացման գրառումը կարող է ժամանակ չունենալ սկավառակի վրա գրվելու համար և արդյունքում կարող է կորչել սերվերի հանկարծակի ձախողման պատճառով։ Օգտագործման շնորհիվ dirsync այս խնդիրներից կարելի է խուսափել:
2. Օպտիմալացում Zimbra ենթակառուցվածքի հետ
Հաճախ է պատահում, որ Zimbra-ից մի քանի տարի օգտագործելուց հետո նրա օգտատերերի թիվը զգալիորեն ավելանում է, և ծառայությունն օրեցօր ավելի ու ավելի քիչ արձագանքող է դառնում։ Այս իրավիճակից ելքը ակնհայտ է՝ պարզապես անհրաժեշտ է ենթակառուցվածքում նոր սերվերներ ավելացնել, որպեսզի ծառայությունը նորից աշխատի նախկինի պես արագ։ Միևնույն ժամանակ, միշտ չէ, որ հնարավոր է անմիջապես ենթակառուցվածքում նոր սերվերներ ավելացնել՝ դրա արդյունավետությունը բարձրացնելու համար։ ՏՏ մենեջերները հաճախ ստիպված են լինում երկար ժամանակ ծախսել նոր սերվերների գնումը հաշվապահական հաշվառման կամ անվտանգության բաժնի հետ համակարգելու համար, բացի այդ, նրանք հաճախ հիասթափվում են մատակարարների կողմից, ովքեր կարող են նոր սերվեր մատակարարել ուշ կամ նույնիսկ սխալ բան մատուցել:
Իհարկե, լավագույնն է ձեր Zimbra ենթակառուցվածքը կառուցել պահուստով, որպեսզի միշտ ունենաք դրա ընդլայնման ռեզերվ և կախված չլինեք որևէ մեկից, սակայն, եթե արդեն սխալ է թույլ տրվել, ՏՏ մենեջերը կարող է միայն հարթել դրա հետևանքները. որքան հնարավոր է շատ: Օրինակ՝ ՏՏ մենեջերը կարող է արտադրողականության փոքր աճի հասնել՝ ժամանակավորապես անջատելով Linux համակարգի ծառայությունները, որոնք աշխատանքի ընթացքում կանոնավոր կերպով մուտք են գործում կոշտ սկավառակներ և, հետևաբար, կարող են բացասաբար ազդել Zimbra-ի աշխատանքի վրա: Այսպիսով, դուք կարող եք ժամանակավորապես անջատել.
autofs, netfs - Հեռակա ֆայլային համակարգի հայտնաբերման ծառայություններ
բաժակ - Տպման ծառայություն
xinetd, vsftpd - Ներկառուցված *NIX ծառայություններ, որոնք հավանաբար ձեզ պետք չեն
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Հեռավոր ընթացակարգով զանգերի ծառայություններ, որոնք սովորաբար օգտագործվում են ցանցային ֆայլային համակարգերի հետ համատեղ
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Zimbra Collaboration Suite-ում ներառված հիմնական կոմունալ ծառայությունների կրկնօրինակները
slocate/updatedb - Քանի որ Zimbra-ն յուրաքանչյուր հաղորդագրություն պահում է առանձին ֆայլում, թարմացված b ծառայության ամեն օր գործարկելը կարող է խնդիրներ առաջացնել, և, հետևաբար, դա հնարավոր է ձեռքով անել սերվերների վրա նվազագույն բեռնվածության ժամանակ:
Այս ծառայությունների անջատման արդյունքում համակարգի ռեսուրսների խնայողությունն այնքան էլ նշանակալի չի լինի, բայց նույնիսկ դա կարող է շատ օգտակար լինել ֆորսմաժորային իրավիճակին մոտ: Երբ նոր սերվերը ավելացվի Zimbra ենթակառուցվածքին, խորհուրդ է տրվում նորից միացնել նախկինում անջատված ծառայությունները:
Կարող եք նաև օպտիմիզացնել Zimbra-ի աշխատանքը՝ syslog ծառայությունը տեղափոխելով առանձին սերվեր, որպեսզի շահագործման ընթացքում այն չբեռնի փոստի պահեստների կոշտ սկավառակները: Այս նպատակների համար հարմար է գրեթե ցանկացած համակարգիչ, նույնիսկ էժանագին մեկ տախտակով Raspberry Pi-ն:
Source: www.habr.com