Ձեռնարկությունում ՏՏ ցանկացած լուծման ներդրումը սկսվում է դիզայնից: Այս փուլում ՏՏ մենեջերը պետք է հաշվարկի սերվերների քանակը և դրանց բնութագրերը, որպեսզի դրանք մի կողմից բավարար լինեն բոլոր օգտատերերի համար, իսկ մյուս կողմից՝ այդ սերվերների գին-որակ հարաբերակցությունը լինի. օպտիմալ և նոր տեղեկատվական համակարգի համար հաշվողական ենթակառուցվածք ստեղծելու ծախսերը լուրջ փոս չեն ստեղծում ձեռնարկության ՏՏ բյուջեում: Եկեք պարզենք, թե ինչպես նախագծել ենթակառուցվածքը ձեռնարկությունում Zimbra Collaboration Suite-ի ներդրման համար:
Zimbra-ի հիմնական առանձնահատկությունը՝ համեմատած այլ լուծումների հետ, այն է, որ ZCS-ի դեպքում շիշը հազվադեպ է դառնում պրոցեսորի հզորություն կամ օպերատիվ հիշողություն։ Հիմնական սահմանափակումը սովորաբար կոշտ սկավառակի մուտքի և ելքի արագությունն է, և, հետևաբար, հիմնական ուշադրությունը պետք է դարձնել տվյալների պահեստներին: Արտադրական միջավայրում Zimbra-ի համար պաշտոնապես հայտարարված նվազագույն պահանջներն են 4 միջուկային 64-բիթանոց պրոցեսորը 2 ԳՀց ժամացույցի արագությամբ, 10 գիգաբայթ համակարգի ֆայլերի և տեղեկամատյանների համար և 8 գիգաբայթ օպերատիվ հիշողություն: Սովորաբար, այս բնութագրերը բավարար են պատասխանատու սերվերի շահագործման համար: Բայց ինչ անել, եթե դուք պետք է իրականացնեք Zimbra-ն 10 օգտագործողների համար: Ո՞ր սերվերները և ինչպե՞ս պետք է ներդրվեն այս դեպքում:
Սկսենք նրանից, որ 10 հազար օգտատերերի համար ենթակառուցվածքը պետք է լինի բազմասերվեր։ Մի կողմից, բազմասերվերային ենթակառուցվածքը հնարավորություն է տալիս Zimbra-ն դարձնել մասշտաբային, իսկ մյուս կողմից՝ հասնել տեղեկատվական համակարգի պատասխանատու աշխատանքի նույնիսկ օգտատերերի մեծ հոսքի դեպքում: Սովորաբար բավականին դժվար է կանխատեսել, թե Zimbra սերվերը քանի օգտվողի կկարողանա լավ սպասարկել, քանի որ շատ բան կախված է օրացույցների և էլեկտրոնային փոստի հետ նրանց աշխատանքի ինտենսիվությունից, ինչպես նաև օգտագործվող արձանագրությունից: Այդ իսկ պատճառով, օրինակ, մենք կիրականացնենք 4 փոստի պահեստավորում։ Հզորության պակասի կամ լուրջ ավելցուկի դեպքում հնարավոր կլինի կա՛մ անջատել, կա՛մ ավելացնել ևս մեկը։
Այսպիսով, 10.000 մարդու համար ենթակառուցվածք նախագծելիս անհրաժեշտ կլինի ստեղծել LDAP, MTA և Proxy սերվերներ և 4 փոստի պահեստներ։ Նշենք, որ LDAP, MTA և Proxy սերվերները կարող են վիրտուալ լինել: Սա կնվազեցնի սերվերի ապարատային արժեքը և կհեշտացնի տվյալների կրկնօրինակումն ու վերականգնումը, բայց մյուս կողմից, ֆիզիկական սերվերի խափանման դեպքում դուք վտանգում եք անմիջապես մնալ առանց MTA, LDAP և Proxy: Այդ իսկ պատճառով ընտրությունը ֆիզիկական կամ վիրտուալ սերվերների միջև պետք է կատարվի՝ ելնելով այն բանից, թե որքան ժամանակ կարող եք ձեզ թույլ տալ արտակարգ իրավիճակների դեպքում: Փոստի պահեստները, մյուս կողմից, լավագույնս տեղադրվելու են ֆիզիկական սերվերների վրա, քանի որ հենց դրանց վրա է տեղի ունենալու գրման ցիկլերի հիմնական թիվը, ինչը սահմանափակում է Zimbra-ի կատարումը, և, հետևաբար, տվյալների փոխանցման ավելի մեծ թվով ալիքներ զգալիորեն կկազմեն: բարձրացնել Zimbra-ի կատարումը:
Սկզբունքորեն, LDAP, MTA, Proxy սերվերներ, ցանցային պահեստներ ստեղծելուց և դրանք մեկ ենթակառուցվածքի մեջ միավորելուց հետո, 10000 օգտվողների համար նախատեսված Zimbra Collaboration Suite-ը պատրաստ է գործարկման: Նման կոնֆիգուրացիայի շահագործման սխեման բավականին պարզ կլինի.
Դիագրամը ցույց է տալիս համակարգի հիմնական հանգույցները և դրանց միջև շրջանառվող տվյալների հոսքերը: Այս կոնֆիգուրացիայի դեպքում ենթակառուցվածքը լիովին անպաշտպան կլինի տվյալների կորստից, սերվերներից որևէ մեկի ձախողման հետ կապված խափանումներից և այլն: Եկեք նայենք, թե ինչպես կարող եք պաշտպանել ձեր ենթակառուցվածքն այս խնդիրներից:
Հիմնական մեթոդը ապարատային ավելորդությունն է: Լրացուցիչ MTA և Proxy հանգույցները կարող են հիմնական սերվերների խափանման դեպքում ժամանակավորապես ստանձնել հիմնական սերվերների դերը: Կրիտիկական ենթակառուցվածքի հանգույցների կրկնօրինակումը գրեթե միշտ հիանալի գաղափար է, բայց միշտ չէ, որ հնարավոր է ցանկալի չափով: Վառ օրինակ է փոստը պահող սերվերների ավելորդությունը: Zimbra Collaboration Suite Open-Source Edition-ը ներկայումս չի աջակցում կրկնօրինակ խանութների ստեղծմանը, հետևաբար, եթե այս սերվերներից մեկը ձախողվի, հնարավոր չէ խուսափել անգործությունից, և փոստի խանութի ձախողման հետևանքով առաջացած աշխատանքը նվազեցնելու համար ՏՏ մենեջերը կարող է տեղադրել դրա կրկնօրինակը: մեկ այլ սերվեր:
Քանի որ Zimbra OSE-ում ներկառուցված պահուստավորման համակարգ չկա, մեզ անհրաժեշտ կլինի Zextras Backup, որն աջակցում է իրական ժամանակի կրկնօրինակում և արտաքին պահեստավորում: Քանի որ Zextras Backup-ը, ամբողջական և աստիճանաբար կրկնօրինակումներ վերցնելիս, բոլոր տվյալները տեղադրում է /opt/zimbra/backup պանակում, խելամիտ կլինի դրա մեջ տեղադրել արտաքին, ցանցային կամ նույնիսկ ամպային պահեստավորում, որպեսզի այն դեպքում, երբ սերվերներից մեկը խափանում է, դուք ունեք մեդիա արդիական կրկնօրինակով արտակարգ իրավիճակի պահին: Այն կարող է տեղակայվել ինչպես ավելորդ ֆիզիկական սերվերի, այնպես էլ վիրտուալ մեքենայի և ամպի վրա: Լավ գաղափար է նաև Zimbra Proxy-ով սերվերի առջև սպամի ֆիլտրով MTA տեղադրել՝ սերվեր մուտք գործող անպետք տրաֆիկի քանակը նվազեցնելու համար:
Արդյունքում, անվտանգ Zimbra ենթակառուցվածքը նման տեսք կունենա.
Այս կոնֆիգուրացիայով Zimbra ենթակառուցվածքը ոչ միայն կկարողանա որակյալ ծառայություններ մատուցել 10.000 օգտատերերի, այլ նաև արտակարգ իրավիճակի դեպքում այն թույլ կտա հնարավորինս արագ վերացնել դրա հետևանքները։
Source: www.habr.com