Zimbra Collaboration Suite တွင် မေးလ်သိုလှောင်မှုကို ကောင်းမွန်အောင်ပြုလုပ်ခြင်း။

ငါတို့ထဲက တစ်ယောက် ယခင်ဆောင်းပါးများလုပ်ငန်းတစ်ခုတွင် Zimbra Collabortion Suite ကိုအကောင်အထည်ဖော်သောအခါတွင် အခြေခံအဆောက်အအုံအစီအစဥ်ရေးဆွဲခြင်းအတွက် ရည်စူးထားသော၊ ဤဖြေရှင်းချက်၏လုပ်ဆောင်မှုတွင် အဓိကကန့်သတ်ချက်မှာ စာပို့သိုလှောင်မှုအတွင်းရှိ disk စက်ပစ္စည်းများ၏ I/O မြန်နှုန်းဖြစ်ကြောင်း ပြောကြားခဲ့ပါသည်။ ဧကန်စင်စစ်၊ လုပ်ငန်းတစ်ခု၏ ဝန်ထမ်းရာပေါင်းများစွာသည် တူညီသောမေးလ်သိုလှောင်မှုကို တစ်ပြိုင်နက်ဝင်ရောက်သည့်အခါ၊ ဟာ့ဒ်ဒရိုက်များမှ အချက်အလက်ရေးသားခြင်းနှင့် ဖတ်ရှုခြင်းအတွက် ချန်နယ်အကျယ်သည် ဝန်ဆောင်မှု၏တုံ့ပြန်မှုလုပ်ဆောင်မှုအတွက် မလုံလောက်နိုင်ပါ။ Zimbra ၏သေးငယ်သောတပ်ဆင်မှုများအတွက်၎င်းသည်အထူးပြဿနာတစ်ခုမဟုတ်ပါက၊ ကြီးမားသောစီးပွားရေးလုပ်ငန်းများနှင့် SaaS ဝန်ဆောင်မှုပေးသူများတွင်၊ ဤအရာအားလုံးသည်တုံ့ပြန်မှုမရှိသောအီးမေးလ်ကိုဖြစ်ပေါ်စေနိုင်ပြီးရလဒ်အနေဖြင့်ဝန်ထမ်းစွမ်းဆောင်ရည်ကျဆင်းခြင်းနှင့်ချိုးဖောက်မှုဖြစ်သည်။ SLA များ။ ထို့ကြောင့်၊ အကြီးစား Zimbra တပ်ဆင်မှုများကို ဒီဇိုင်းဆွဲပြီး လုပ်ဆောင်သည့်အခါ၊ မေးလ်သိုလှောင်မှုတွင် ဟာ့ဒ်ဒရိုက်များ၏ စွမ်းဆောင်ရည်ကို အကောင်းဆုံးဖြစ်အောင် အထူးအာရုံစိုက်သင့်သည်။ ဖြစ်ရပ်နှစ်ခုကိုကြည့်ရအောင်၊ ၎င်းတို့တစ်ခုစီတွင် ဒစ်ခ်သိုလှောင်မှုအပေါ် ဝန်ပိုကောင်းအောင်ပြုလုပ်ရန် မည်သည့်နည်းလမ်းများကို ၎င်းတို့တစ်ခုစီတွင် အသုံးချနိုင်သည်ကို ရှာဖွေကြည့်ပါ။

Zimbra Collaboration Suite တွင် မေးလ်သိုလှောင်မှုကို ကောင်းမွန်အောင်ပြုလုပ်ခြင်း။

1. အကြီးစား Zimbra တပ်ဆင်ခြင်းအား ဒီဇိုင်းဆွဲသည့်အခါ ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်း။

Zimbra တပ်ဆင်မှု၏ ဒီဇိုင်းအဆင့်တွင်၊ စီမံခန့်ခွဲသူက မည်သည့်သိုလှောင်မှုစနစ်ကို အသုံးပြုရမည်ကို ရွေးချယ်ရမည်ဖြစ်သည်။ ဤပြဿနာကို ဆုံးဖြတ်ရန်အတွက်၊ hard drive များရှိ အဓိက load သည် Zimbra Collaboration Suite၊ Apache Lucene ရှာဖွေရေးအင်ဂျင်နှင့် blob သိုလှောင်မှုတွင် ပါဝင်သော MariaDB DBMS မှ လာကြောင်း သင်သိထားသင့်သည်။ ထို့ကြောင့် ဤဆော့ဖ်ဝဲထုတ်ကုန်များကို မြင့်မားသောဝန်အခြေအနေအောက်တွင် လည်ပတ်နိုင်ရန်၊ မြန်နှုန်းမြင့်ပြီး ယုံကြည်စိတ်ချရသော စက်ကိရိယာများကို အသုံးပြုရန် လိုအပ်ပါသည်။

ပုံမှန်အခြေအနေအောက်တွင် Zimbra ကို ဟာ့ဒ်ဒရိုက်များ၏ RAID နှင့် NFS ပရိုတိုကောမှတစ်ဆင့် ချိတ်ဆက်ထားသော သိုလှောင်မှုတွင် နှစ်ခုလုံးထည့်သွင်းနိုင်သည်။ အလွန်သေးငယ်သော တပ်ဆင်မှုများအတွက်၊ သင်သည် ပုံမှန် SATA drive တစ်ခုတွင် Zimbra ကို ထည့်သွင်းနိုင်သည်။ သို့သော်လည်း ကြီးမားသော တပ်ဆင်မှုများ၏ အခြေအနေတွင်၊ ဤနည်းပညာများအားလုံးသည် မှတ်တမ်းတင်ခြင်းအမြန်နှုန်း လျှော့ချခြင်း သို့မဟုတ် ယုံကြည်စိတ်ချရမှု နည်းပါးခြင်းပုံစံဖြင့် အားနည်းချက်များစွာကို ပြသသည်၊ ၎င်းသည် လုပ်ငန်းကြီးများနှင့် အထူးသဖြင့် SaaS ဝန်ဆောင်မှုပေးသူများအတွက် လက်မခံနိုင်ပါ။

ထို့ကြောင့် ကြီးမားသော Zimbra အခြေခံအဆောက်အအုံများတွင် SAN ကို အသုံးပြုခြင်းသည် အကောင်းဆုံးဖြစ်သည်။ ၎င်းသည် လက်ရှိတွင် သိုလှောင်ကိရိယာများအတွက် အကြီးမားဆုံးသော ဖြတ်သန်းစီးဆင်းမှုကို ပေးစွမ်းနိုင်သည့် ဤနည်းပညာဖြစ်ပြီး တစ်ချိန်တည်းတွင် ကက်ရှ်အများအပြားကို ချိတ်ဆက်နိုင်ခြင်းကြောင့် ၎င်း၏အသုံးပြုမှုသည် လုပ်ငန်းအတွက် သိသိသာသာ အန္တရာယ်များမဖြစ်စေပါ။ စာရေးနေစဉ်အတွင်း အရာများကို မြန်ဆန်စေရန် SAN အများအပြားတွင် အသုံးပြုသည့် NVRAM ကို အသုံးပြုခြင်းသည် ကောင်းမွန်ပါသည်။ သို့သော် ၎င်းသည် မီဒီယာအား ပြန်လည်ပြုပြင်၍မရသော ပျက်စီးမှုနှင့် ပါဝါပြဿနာများဖြစ်ပွားပါက ဒေတာဆုံးရှုံးမှုများဖြစ်ပေါ်စေနိုင်သောကြောင့် disks များပေါ်တွင် မှတ်တမ်းတင်ထားသော ဒေတာများကို ၎င်းတို့ကိုယ်တိုင် သိမ်းဆည်းခြင်းအား ပိတ်ခြင်းသည် ပိုကောင်းပါသည်။

ဖိုင်စနစ်ရွေးချယ်ရာတွင် အကောင်းဆုံးရွေးချယ်မှုမှာ စံ Linux Ext3/Ext4 ကို အသုံးပြုရန်ဖြစ်သည်။ ဖိုင်စနစ်နှင့် ဆက်စပ်နေသော အဓိက ကွဲပြားချက်မှာ ၎င်းကို ပါရာမီတာဖြင့် တပ်ဆင်သင့်သည်။ -noatime. ဤရွေးချယ်မှုသည် ဖိုင်များထံ နောက်ဆုံးဝင်ရောက်အသုံးပြုချိန်ကို မှတ်တမ်းတင်ခြင်း၏လုပ်ဆောင်ချက်ကို ပိတ်ပစ်မည်ဖြစ်ပြီး ဆိုလိုသည်မှာ ၎င်းသည် စာဖတ်ခြင်းနှင့် စာရေးခြင်းတွင် ဝန်ကို များစွာလျှော့ချပေးမည်ဖြစ်သည်။ ယေဘူယျအားဖြင့် Zimbra အတွက် ext3 သို့မဟုတ် ext4 ဖိုင်စနစ်တစ်ခုကို ဖန်တီးသောအခါ၊ သင်သည် အောက်ပါ utility parameters များကို အသုံးပြုသင့်သည်။ mke2fs:

-j — ဖိုင်စနစ်ဂျာနယ်ဖန်တီးရန်၊ ext3/ext4 ဂျာနယ်ဖြင့် ဖိုင်စနစ်ဖန်တီးပါ။
-L NAME - ထို့နောက် /etc/fstab တွင်အသုံးပြုရန် volume အမည်တစ်ခုဖန်တီးရန်
-O dir_index - ကြီးမားသောလမ်းကြောင်းများတွင် ဖိုင်ရှာဖွေမှုများကို အရှိန်မြှင့်ရန် hashed search tree ကိုအသုံးပြုရန်
-m ၆၄ - root directory အတွက် ကြီးမားသော ဖိုင်စနစ်များတွင် ပမာဏ၏ 2% ကို သိမ်းဆည်းရန်
-J အရွယ်အစား = 400 - မဂ္ဂဇင်းကြီးတစ်ခုဖန်တီးရန်
-b ၄၀၉၆ - bytes ဖြင့် block အရွယ်အစားကို ဆုံးဖြတ်ရန်
-i ၀ - မက်ဆေ့ချ်သိုလှောင်မှုအတွက်၊ ဤဆက်တင်သည် ပျမ်းမျှမက်ဆေ့ချ်အရွယ်အစားနှင့် ကိုက်ညီသင့်သည်။ ၎င်း၏တန်ဖိုးကို နောက်ပိုင်းတွင် ပြောင်းလဲ၍မရသောကြောင့် ဤကန့်သတ်ချက်ကို သေချာအာရုံစိုက်သင့်သည်။

၎င်းကိုဖွင့်ရန်လည်းအကြံပြုထားသည်။ disync blob သိုလှောင်မှု၊ Lucene ရှာဖွေမှု မက်တာဒေတာသိုလှောင်မှုနှင့် MTA တန်းစီသိမ်းဆည်းမှုတို့အတွက်။ Zimbra သည် အများအားဖြင့် utility ကိုအသုံးပြုသောကြောင့် ၎င်းကိုလုပ်ဆောင်သင့်သည်။ fsync ဒေတာကို disk သို့ blob တစ်ခု၏အာမခံချက်အတွက်ရေးသားခြင်း။ သို့သော်၊ Zimbra မေးလ်စတိုး သို့မဟုတ် MTA သည် မက်ဆေ့ချ်ပေးပို့စဉ်အတွင်း ဖိုင်အသစ်များဖန်တီးသည့်အခါ သက်ဆိုင်ရာဖိုင်တွဲများတွင် ဖြစ်ပေါ်သည့်ပြောင်းလဲမှုများကို disk သို့ စာရေးရန် လိုအပ်လာသည်။ အဲဒါကြောင့် ဖိုင်ကို ဒစ်ခ်မှာ ရေးပြီးသွားရင်တောင်မှ သုံးပါတယ်။ fsync၊ ဖိုင်လမ်းညွှန်တွင် ၎င်း၏ မှတ်တမ်းသည် ဒစ်ခ်သို့ စာရေးရန် အချိန်မရှိနိုင်သဖြင့် ရလဒ်မှာ ရုတ်တရက် ဆာဗာချို့ယွင်းမှုကြောင့် ဆုံးရှုံးသွားနိုင်သည်။ အသုံးပြုမှုအား ကျေးဇူးတင်ပါသည်။ disync ဒီပြဿနာတွေကို ရှောင်ရှားနိုင်ပါတယ်။

2. Zimbra အခြေခံအဆောက် အအုံဖြင့် ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်ခြင်း။

Zimbra ကို နှစ်အတော်ကြာ အသုံးပြုပြီးနောက်၊ ၎င်း၏ အသုံးပြုသူ အရေအတွက် သိသိသာသာ တိုးလာပြီး ဝန်ဆောင်မှုသည် နေ့စဉ်နှင့်အမျှ တုံ့ပြန်မှု နည်းပါးလာကာ မကြာခဏဆိုသလို ဖြစ်တတ်ပါသည်။ ဤအခြေအနေမှလွတ်မြောက်ရန်နည်းလမ်းမှာ သိသာထင်ရှားပါသည်- ဝန်ဆောင်မှုသည် ယခင်ကဲ့သို့ လျင်မြန်စွာပြန်လည်အလုပ်လုပ်နိုင်စေရန်အတွက် အခြေခံအဆောက်အဦတွင် ဆာဗာအသစ်များထည့်ရန် လိုအပ်ပါသည်။ ဤအတောအတွင်း၊ ၎င်း၏စွမ်းဆောင်ရည်ကို မြှင့်တင်ရန်အတွက် အခြေခံအဆောက်အအုံတွင် ဆာဗာအသစ်များကို ချက်ချင်းထည့်သွင်းရန် အမြဲတမ်းမဖြစ်နိုင်ပါ။ အိုင်တီမန်နေဂျာများသည် စာရင်းအင်း သို့မဟုတ် လုံခြုံရေးဌာနနှင့် ဆာဗာအသစ်များဝယ်ယူရာတွင် အချိန်အကြာကြီး ညှိနှိုင်းပေးရလေ့ရှိသည်၊ ထို့အပြင် ဆာဗာအသစ်ကို နောက်ကျမှ ပို့ဆောင်ပေးနိုင်သော သို့မဟုတ် မှားယွင်းသည့်အရာများကို ပေးဆောင်နိုင်သည့် ပေးသွင်းသူများမှ မကြာခဏ နှိမ့်ချခံရလေ့ရှိသည်။

ဟုတ်ပါတယ်၊၊ ၎င်း၏တိုးချဲ့မှုအတွက်အရံအရံအမြဲရှိရန်နှင့်မည်သူ့ကိုမျှမမူတည်စေရန်သင်၏ Zimbra အခြေခံအဆောက်အအုံကိုအရန်အရံတစ်ခုဖြင့်တည်ဆောက်ခြင်းသည်အကောင်းဆုံးဖြစ်သည်၊ သို့သော်၊ အမှားတစ်ခုပြုလုပ်ပြီးပါက IT မန်နေဂျာသည်၎င်း၏အကျိုးဆက်များကိုသာချောမွေ့စွာဖြေရှင်းနိုင်သည်။ တတ်နိုင်သမျှ ဥပမာအားဖြင့်၊ အိုင်တီမန်နေဂျာသည် လည်ပတ်နေစဉ်အတွင်း hard drives များကို ပုံမှန်ဝင်ရောက်နိုင်သော Linux စနစ်ဝန်ဆောင်မှုများကို ယာယီပိတ်ထားခြင်းဖြင့် Zimbra ၏စွမ်းဆောင်ရည်ကို အပျက်သဘောဆောင်သောအကျိုးသက်ရောက်မှုဖြစ်စေနိုင်သည်။ ထို့ကြောင့် သင်သည် ယာယီပိတ်နိုင်သည်-

autofs၊ netfs - အဝေးထိန်းဖိုင်စနစ် ရှာဖွေတွေ့ရှိမှု ဝန်ဆောင်မှုများ
ခွက် - ပုံနှိပ်ခြင်းဝန်ဆောင်မှု
Xinetd၊ vsftpd - သင် မလိုအပ်တော့သည့် * NIX ဝန်ဆောင်မှုများ ပါ၀င်ပါသည်။
portmap၊ rpcsvcgssd၊ rpcgssd၊ rpcidmapd — အများအားဖြင့် ကွန်ရက်ဖိုင်စနစ်များနှင့် တွဲဖက်အသုံးပြုလေ့ရှိသည့် အဝေးထိန်းလုပ်ငန်းစဉ်ခေါ်ဆိုမှုဝန်ဆောင်မှုများ
dovecot၊ cyrus-imapd၊ sendmail၊ exim၊ postfix၊ ldap - Zimbra Collaboration Suite တွင်ပါရှိသော ပင်မအသုံးအဆောင်များ၏ မိတ္တူများ
နေရာချထား/မွမ်းမံခြင်းb - Zimbra သည် မက်ဆေ့ချ်တစ်ခုစီကို သီးခြားဖိုင်တစ်ခုတွင် သိမ်းဆည်းထားသောကြောင့် updateb ဝန်ဆောင်မှုကို နေ့စဉ်အသုံးပြုခြင်းသည် ပြဿနာများကို ဖြစ်စေနိုင်ပြီး ဆာဗာများတွင် တင်အနည်းဆုံးကာလအတွင်း ၎င်းကို ကိုယ်တိုင်လုပ်ဆောင်နိုင်သည်

ဤဝန်ဆောင်မှုများကို ပိတ်လိုက်ခြင်းကြောင့် စနစ်ရင်းမြစ်များကို သိမ်းဆည်းခြင်းမှာ အလွန်အရေးပါမည်မဟုတ်သော်လည်း၊ ဤအရာသည် အင်အားကြီးမားသည့်အခြေအနေများနှင့် နီးစပ်သည့်အခြေအနေများတွင်ပင် အသုံးဝင်နိုင်ပါသည်။ ဆာဗာအသစ်ကို Zimbra အခြေခံအဆောက်အအုံသို့ ပေါင်းထည့်လိုက်သည်နှင့်၊ ယခင်ပိတ်ထားခဲ့သော ဝန်ဆောင်မှုများကို ပြန်လည်ဖွင့်ရန် အကြံပြုထားသည်။

လည်ပတ်နေစဉ်အတွင်း ၎င်းသည် မေးလ်သိုလှောင်မှု၏ ဟာ့ဒ်ဒရိုက်များကို မတင်နိုင်အောင် syslog ဝန်ဆောင်မှုကို သီးခြားဆာဗာသို့ ရွှေ့ခြင်းဖြင့် Zimbra ၏ လုပ်ဆောင်ချက်ကို အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်နိုင်သည်။ စျေးပေါသော single-board Raspberry Pi ပင် ဤရည်ရွယ်ချက်များအတွက် မည်သည့်ကွန်ပျူတာမဆို သင့်လျော်ပါသည်။

source: www.habr.com

မှတ်ချက် Add