Մեր մեկում Ձեռնարկությունում 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 ենթակառուցվածքը կառուցել պահուստային տարբերակով, որպեսզի միշտ ունենաք ընդլայնման տեղ և ստիպված չլինեք որևէ մեկի վրա հույս դնել: Այնուամենայնիվ, եթե արդեն սխալ է թույլ տրվել, IT մենեջերը կարող է միայն հնարավորինս մեղմել դրա հետևանքները: Օրինակ, IT մենեջերը կարող է հասնել արտադրողականության փոքր բարձրացման՝ ժամանակավորապես անջատելով համակարգային ծառայությունները: Linux, որոնք աշխատանքի ընթացքում պարբերաբար մուտք են գործում կոշտ սկավառակների վրա և, որպես արդյունք, կարող են բացասաբար ազդել Zimbra-ի աշխատանքի վրա: Օրինակ, կարող եք ժամանակավորապես անջատել՝
autofs, netfs - Հեռակա ֆայլային համակարգի հայտնաբերման ծառայություններ
բաժակ - Տպման ծառայություն
xinetd, vsftpd - Ներկառուցված *NIX ծառայություններ, որոնք հավանաբար ձեզ պետք չեն
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — Հեռավոր ընթացակարգով զանգերի ծառայություններ, որոնք սովորաբար օգտագործվում են ցանցային ֆայլային համակարգերի հետ համատեղ
աղավնանոց, cyrus-imapd, sendmail, exim, postfix, ldap — Zimbra Collaboration Suite-ում ներառված հիմնական կոմունալ ծառայությունների կրկնօրինակները
slocate/updatedb - Քանի որ Zimbra-ն յուրաքանչյուր հաղորդագրություն պահում է առանձին ֆայլում, թարմացված b ծառայության ամեն օր գործարկելը կարող է խնդիրներ առաջացնել, և, հետևաբար, դա հնարավոր է ձեռքով անել սերվերների վրա նվազագույն բեռնվածության ժամանակ:
Այս ծառայությունների անջատման արդյունքում համակարգի ռեսուրսների խնայողությունն այնքան էլ նշանակալի չի լինի, բայց նույնիսկ դա կարող է շատ օգտակար լինել ֆորսմաժորային իրավիճակին մոտ: Երբ նոր սերվերը ավելացվի Zimbra ենթակառուցվածքին, խորհուրդ է տրվում նորից միացնել նախկինում անջատված ծառայությունները:
Կարող եք նաև օպտիմիզացնել Zimbra-ի աշխատանքը՝ syslog ծառայությունը տեղափոխելով առանձին սերվեր, որպեսզի շահագործման ընթացքում այն չբեռնի փոստի պահեստների կոշտ սկավառակները: Այս նպատակների համար հարմար է գրեթե ցանկացած համակարգիչ, նույնիսկ էժանագին մեկ տախտակով Raspberry Pi-ն:
Source: www.habr.com
