झिंब्रा कोलॅबोरेशन सूटमध्ये मेल स्टोरेज ऑप्टिमाइझ करत आहे

आमच्या एका मध्ये मागील लेख, एखाद्या एंटरप्राइझमध्ये Zimbra Collabortion Suite लागू करताना पायाभूत सुविधांच्या नियोजनासाठी समर्पित, असे म्हटले गेले की या सोल्यूशनच्या ऑपरेशनमध्ये मुख्य मर्यादा ही मेल स्टोरेजमधील डिस्क उपकरणांची I/O गती आहे. खरंच, जेव्हा एंटरप्राइझचे शेकडो कर्मचारी एकाच वेळी समान मेल स्टोरेजमध्ये प्रवेश करतात तेव्हा, हार्ड ड्राइव्हवरून माहिती लिहिण्यासाठी आणि वाचण्यासाठी चॅनेलची रुंदी सेवेच्या प्रतिसादात्मक ऑपरेशनसाठी पुरेशी असू शकत नाही. आणि जर झिम्ब्राच्या छोट्या स्थापनेसाठी ही एक विशिष्ट समस्या नसेल, तर मोठ्या उद्योग आणि सास प्रदात्यांच्या बाबतीत, हे सर्व प्रतिसाद न देणारे ईमेल होऊ शकते आणि परिणामी, कर्मचार्‍यांच्या कार्यक्षमतेत घट, तसेच उल्लंघन. SLAs चे. म्हणूनच, मोठ्या प्रमाणात झिंब्रा इंस्टॉलेशन्स डिझाइन आणि ऑपरेट करताना, मेल स्टोरेजमध्ये हार्ड ड्राइव्हच्या कार्यप्रदर्शनास अनुकूल करण्यासाठी विशेष लक्ष दिले पाहिजे. चला दोन प्रकरणे पाहू आणि त्या प्रत्येकामध्ये डिस्क स्टोरेजवरील लोड ऑप्टिमाइझ करण्यासाठी कोणत्या पद्धती लागू केल्या जाऊ शकतात हे शोधण्याचा प्रयत्न करूया.

1. मोठ्या प्रमाणात झिंब्रा इंस्टॉलेशन डिझाइन करताना ऑप्टिमायझेशन

हाय-लोड झिंब्रा इन्स्टॉलेशनच्या डिझाईन टप्प्यादरम्यान, कोणती स्टोरेज सिस्टम वापरायची याबद्दल प्रशासकाला निवड करावी लागेल. या समस्येवर निर्णय घेण्यासाठी, तुम्हाला माहित असले पाहिजे की हार्ड ड्राइव्हवरील मुख्य भार झिंब्रा कोलॅबोरेशन सूट, Apache Lucene शोध इंजिन आणि ब्लॉब स्टोरेजमध्ये समाविष्ट असलेल्या MariaDB DBMS मधून येतो. म्हणूनच ही सॉफ्टवेअर उत्पादने उच्च लोड स्थितीत ऑपरेट करण्यासाठी, उच्च-गती आणि विश्वासार्ह उपकरणे वापरणे आवश्यक आहे.

सामान्य परिस्थितीत, झिंब्रा हार्ड ड्राइव्हच्या RAID वर आणि NFS प्रोटोकॉलद्वारे कनेक्ट केलेल्या स्टोरेजवर दोन्ही स्थापित केले जाऊ शकते. अगदी लहान स्थापनेसाठी, आपण नियमित SATA ड्राइव्हवर झिंब्रा स्थापित करू शकता. तथापि, मोठ्या स्थापनेच्या संदर्भात, हे सर्व तंत्रज्ञान कमी रेकॉर्डिंग गती किंवा कमी विश्वासार्हतेच्या रूपात विविध तोटे प्रदर्शित करतात, जे मोठ्या उद्योगांसाठी किंवा विशेषतः SaaS प्रदात्यांसाठी अस्वीकार्य आहे.

म्हणूनच मोठ्या प्रमाणावर झिंब्रा पायाभूत सुविधांमध्ये SAN वापरणे चांगले. हे तंत्रज्ञान आहे जे सध्या स्टोरेज डिव्हाइसेससाठी सर्वात मोठे थ्रूपुट प्रदान करण्यास सक्षम आहे आणि त्याच वेळी, मोठ्या प्रमाणात कॅशे कनेक्ट करण्याच्या क्षमतेबद्दल धन्यवाद, त्याचा वापर व्यावहारिकरित्या एंटरप्राइझसाठी कोणतेही महत्त्वपूर्ण जोखीम निर्माण करत नाही. NVRAM वापरणे चांगली कल्पना आहे, जे लेखन दरम्यान गोष्टींना गती देण्यासाठी अनेक SAN मध्ये वापरले जाते. परंतु डिस्कवर रेकॉर्ड केलेल्या डेटाचे कॅशिंग स्वतः अक्षम करणे चांगले आहे, कारण यामुळे मीडियाचे अपूरणीय नुकसान होऊ शकते आणि पॉवर समस्या उद्भवल्यास डेटा गमावू शकतो.

फाईल सिस्टीम निवडण्यासाठी, मानक लिनक्स एक्स्ट३/एक्सट४ वापरणे हा सर्वोत्तम पर्याय असेल. फाइल सिस्टमशी संबंधित मुख्य सूक्ष्मता म्हणजे ती पॅरामीटरसह माउंट केली जावी -नोटाईम. हा पर्याय फायलींमध्ये शेवटच्या प्रवेशाची वेळ रेकॉर्ड करण्याचे कार्य अक्षम करेल, याचा अर्थ ते वाचन आणि लेखनावरील भार मोठ्या प्रमाणात कमी करेल. सर्वसाधारणपणे, Zimbra साठी ext3 किंवा ext4 फाइल सिस्टम तयार करताना, तुम्ही खालील उपयुक्तता पॅरामीटर्स वापरावेत mke2fs:

-j — फाइल सिस्टम जर्नल तयार करण्यासाठी ext3/ext4 जर्नलसह फाइल सिस्टम तयार करा.
-एल नाव - नंतर /etc/fstab मध्ये वापरण्यासाठी व्हॉल्यूम नाव तयार करण्यासाठी
-O dir_index - मोठ्या डिरेक्टरीमध्ये फाइल शोधांना गती देण्यासाठी हॅश केलेले शोध वृक्ष वापरणे
-एम 2 — रूट डिरेक्ट्रीसाठी मोठ्या फाइल सिस्टममध्ये व्हॉल्यूमच्या 2% आरक्षित करण्यासाठी
-जे आकार = 400 - एक मोठे मासिक तयार करण्यासाठी
-बी 4096 - बाइट्समध्ये ब्लॉक आकार निश्चित करण्यासाठी
-मी 10240 - संदेश संचयनासाठी, ही सेटिंग सरासरी संदेश आकाराशी संबंधित असावी. आपण या पॅरामीटरकडे लक्षपूर्वक लक्ष दिले पाहिजे, कारण त्याचे मूल्य नंतर बदलले जाऊ शकत नाही.

हे सक्षम करण्याची देखील शिफारस केली जाते dirsync ब्लॉब स्टोरेज, लुसीन सर्च मेटाडेटा स्टोरेज आणि MTA क्यू स्टोरेजसाठी. हे केले पाहिजे कारण झिंब्रा सहसा उपयुक्तता वापरते fsync डिस्कवर डेटासह ब्लॉबच्या हमी लेखनासाठी. तथापि, जेव्हा संदेश वितरणादरम्यान झिंब्रा मेल स्टोअर किंवा MTA नवीन फाइल्स तयार करते, तेव्हा संबंधित फोल्डर्समध्ये होणारे बदल डिस्कवर लिहिणे आवश्यक होते. म्हणूनच, फाइल आधीच डिस्कवर वापरून लिहिली गेली असली तरीही fsync, डिरेक्ट्रीमध्ये त्याच्या जोडण्याच्या रेकॉर्डला डिस्कवर लिहिण्यासाठी वेळ नसू शकतो आणि परिणामी, अचानक सर्व्हरच्या अपयशामुळे गमावले जाऊ शकते. वापरल्याबद्दल धन्यवाद dirsync या समस्या टाळता येतात.

2. झिंब्रा पायाभूत सुविधांसह ऑप्टिमायझेशन चालू आहे

हे बर्याचदा घडते की झिंब्रा वापरल्यानंतर अनेक वर्षांनी, त्याच्या वापरकर्त्यांची संख्या लक्षणीय वाढते आणि सेवा दररोज कमी आणि कमी प्रतिसाद देते. या परिस्थितीतून बाहेर पडण्याचा मार्ग स्पष्ट आहे: आपल्याला फक्त पायाभूत सुविधांमध्ये नवीन सर्व्हर जोडण्याची आवश्यकता आहे जेणेकरून सेवा पुन्हा पूर्वीप्रमाणेच कार्य करेल. दरम्यान, त्याची कार्यक्षमता वाढवण्यासाठी पायाभूत सुविधांमध्ये नवीन सर्व्हर त्वरित जोडणे नेहमीच शक्य नसते. आयटी व्यवस्थापकांना नवीन सर्व्हरच्या खरेदीसाठी लेखा किंवा सुरक्षा विभागाशी समन्वय साधण्यात बराच वेळ घालवावा लागतो; याव्यतिरिक्त, नवीन सर्व्हर उशिरा वितरीत करणार्‍या किंवा चुकीची गोष्ट वितरीत करू शकणार्‍या पुरवठादारांद्वारे त्यांना अनेकदा निराश केले जाते.

अर्थात, आपल्या झिम्ब्राच्या पायाभूत सुविधांच्या विस्तारासाठी नेहमी राखीव राखीव ठेवण्यासाठी आणि कोणावरही अवलंबून न राहण्यासाठी रिझर्व्हसह तयार करणे चांगले आहे, तथापि, जर आधीच चूक झाली असेल तर, आयटी व्यवस्थापक केवळ त्याचे परिणाम गुळगुळीत करू शकतात. शक्य तितके. उदाहरणार्थ, IT व्यवस्थापक लिनक्स सिस्टम सेवा तात्पुरते अक्षम करून एक लहान उत्पादकता वाढवू शकतो जे ऑपरेशन दरम्यान हार्ड ड्राइव्हवर नियमितपणे प्रवेश करतात आणि त्यामुळे झिम्ब्राच्या कार्यक्षमतेवर नकारात्मक परिणाम करू शकतात. म्हणून, आपण तात्पुरते अक्षम करू शकता:

autofs, netfs - रिमोट फाइल सिस्टम डिस्कव्हरी सेवा
कप - मुद्रण सेवा
xinetd, vsftpd - अंगभूत *NIX सेवा ज्यांची तुम्हाला कदाचित गरज भासणार नाही
portmap, rpcsvcgssd, rpcgssd, rpcidmapd — दूरस्थ प्रक्रिया कॉल सेवा, ज्याचा वापर सहसा नेटवर्क फाइल सिस्टमसह केला जातो
dovecot, cyrus-imapd, sendmail, exim, postfix, ldap — Zimbra Collaboration Suite मध्ये समाविष्ट असलेल्या मुख्य युटिलिटीजची डुप्लिकेट
slocate/updatedb - झिंब्रा प्रत्येक संदेश एका वेगळ्या फाईलमध्ये संग्रहित करत असल्याने, दररोज अद्यतनित सेवा चालवण्यामुळे समस्या उद्भवू शकतात आणि म्हणूनच सर्व्हरवरील कमीतकमी लोड दरम्यान हे व्यक्तिचलितपणे करणे शक्य आहे.

या सेवा अक्षम केल्यामुळे सिस्टम संसाधने जतन करणे फारसे महत्त्वपूर्ण होणार नाही, परंतु सक्तीच्या घटनेच्या जवळच्या परिस्थितीतही हे खूप उपयुक्त ठरू शकते. एकदा नवीन सर्व्हर झिंब्रा इन्फ्रास्ट्रक्चरमध्ये जोडल्यानंतर, पूर्वी अक्षम केलेल्या सेवा पुन्हा सक्षम करण्याची शिफारस केली जाते.

तुम्ही सिस्लॉग सेवेला वेगळ्या सर्व्हरवर हलवून झिम्ब्राचे ऑपरेशन देखील ऑप्टिमाइझ करू शकता जेणेकरून ऑपरेशन दरम्यान ते मेल स्टोरेजच्या हार्ड ड्राइव्हस् लोड करणार नाही. या हेतूंसाठी जवळजवळ कोणताही संगणक योग्य आहे, अगदी स्वस्त सिंगल-बोर्ड रास्पबेरी पाई देखील.

स्त्रोत: www.habr.com