क्षेत्र और डेटा रेजीडेंसी

आपकी साइटें वहीं चलती हैं जहाँ आप उन्हें चलाना चाहते हैं

इस प्लेटफ़ॉर्म पर क्षेत्र (रीजन) कोई सहायता टिकट नहीं है — यह साइट की एक विशेषता है, जिसे हर बार कुछ डिप्लॉय किए जाने पर प्लेसमेंट इंजन द्वारा सम्मानित किया जाता है। जब आप कोई साइट बनाते हैं, तो आप उस डेटा सेंटर को चुनते हैं जिसे उसकी होस्टिंग लाइन आज पेश करती है, और प्रत्येक डिप्लॉय उस स्थान पर बेड़े की क्षमता पर जाता है, जिसके आगे एक वैश्विक एज होता है। प्रत्येक होस्टिंग पृष्ठ उन शहरों को लाइव पढ़कर सूचीबद्ध करता है।

विभिन्न क्षेत्रों में एज नोड्स के प्रसार में वितरित एक साइट।
  • 7,00,000+दुनिया भर में होस्ट की गई साइटें
  • आप चुनेंप्रत्येक साइट के लिए डेटा केंद्र
  • 99.99%अपटाइम आश्वासन
  • 58पैनल की भाषाएँ

हम कहाँ काम करते हैं

प्रत्येक स्थान के पीछे दो चीज़ें होती हैं: वर्कर फ़्लीट जो आपकी साइटों को चलाता है, और कंट्रोल प्लेन जो उनका प्रबंधन करता है। दोनों क्षेत्र-जागरूक हैं। आप कौन सा स्थान चुनते हैं यह आपकी पसंद है; इसके अंतर्गत क्षमता हमारी अपनी व्यवस्था है, और हम जानबूझकर एक से अधिक आपूर्तिकर्ताओं का उपयोग करते हैं ताकि कोई एक आपूर्तिकर्ता ही पूरा प्लेटफ़ॉर्म न बन जाए।

प्रति साइट चुना गया

प्रत्येक होस्टिंग लाइन डेटा केंद्रों का अपना सेट प्रदान करती है। साइट बनाते समय आप एक का चयन करते हैं, और ऑर्डर फॉर्म केवल वही शहर दिखाता है जहाँ उस लाइन में आज जगह उपलब्ध है।

लाइव सूचीबद्ध

प्रत्येक होस्टिंग पृष्ठ और ऑर्डर फ़ॉर्म पर दिखने वाले शहर प्लेसमेंट इंजन से पढ़े जाते हैं, इसलिए क्षमता उपलब्ध होने के दिन ही नया स्थान दिखाई देने लगता है, और पूर्ण क्षमता वाले स्थान की पेशकश नहीं की जाती है।

प्लेसमेंट वास्तव में कैसे काम करता है

साइट बनाए जाने के क्षण में ही कोड द्वारा क्षेत्र लागू किया जाता है — न कि किसी ऑपरेटर द्वारा यह याद रखने से कि किस बॉक्स का उपयोग करना है।

प्रत्येक वर्कर टैग किया गया है

फ्लीट का प्रत्येक होस्ट एक क्षेत्र कुंजी, एक उत्पाद-पंक्ति आत्मीयता सूची, एक वेब-सर्वर प्रकार और एक क्षमता आंकड़े के साथ खुद को पंजीकृत करता है, फिर काम लेता है। प्लेसमेंट सेवा उम्मीदवारों को पहले क्षेत्र, फिर उत्पाद-पंक्ति, फिर खाली क्षमता के आधार पर फ़िल्टर करती है, और सबसे कम लोड वाले योग्य होस्ट को चुनती है।

साइट क्षेत्र को इनहेरिट करती है और बनाए रखती है

यदि आपने कोई क्षेत्र पिन किया है, तो केवल उस क्षेत्र के वर्कर ही योग्य हैं। यदि आपने ऐसा नहीं किया है, तो साइट उस वर्कर के क्षेत्र को इनहेरिट करती है जिस पर वह आती है और वह मान साइट पर संग्रहीत हो जाता है — इसलिए आपका डेटा कहाँ रहता है इसका रिकॉर्ड एक फ़ील्ड है जिसे आप पढ़ सकते हैं, कोई अनुमान नहीं।

क्षमता परमाणु रूप से प्राप्त की जाती है

प्लेसमेंट एक सशर्त अपडेट के साथ क्षमता का दावा करता है जो केवल तभी सफल होता है जब वर्कर अभी भी सक्रिय हो, अभी भी डिप्लॉय स्वीकार कर रहा हो और अभी भी क्षमता से कम हो। अंतिम स्लॉट के लिए प्रतिस्पर्धा करने वाले दो डिप्लॉय दोनों सफल नहीं हो सकते, इसलिए किसी भी क्षेत्र में कभी भी चुपचाप क्षमता से अधिक आवंटन नहीं होता है।

गलत क्षेत्र में कोई शांत फ़ॉलबैक नहीं

यदि आपके क्षेत्र में किसी भी योग्य संसाधन में स्थान नहीं है, तो डिप्लॉय एक प्लेसमेंट त्रुटि उत्पन्न करता है और रुक जाता है। यह अनुरोध को सफल बनाने के लिए किसी अन्य महाद्वीप पर नहीं जाता है। बिना बताए देश बदल लेने वाली साइट की तुलना में एक स्पष्ट विफलता और क्षमता विस्तार कहीं बेहतर है।

बाधा के बजाय ड्रेन

प्रत्येक worker में एक accepts-deploys स्विच होता है। इसे drain पर करने से नई साइटों का आना बंद हो जाता है जबकि मौजूदा साइटें बिना किसी रुकावट के चलती रहती हैं, जिससे हम आपके वर्कलोड को स्थानांतरित किए बिना किसी क्षेत्र के भीतर रखरखाव, हार्डवेयर रिफ्रेश और डिकमीशनिंग का कार्य करते हैं।

उत्पाद निर्णय के रूप में डेटा रेजीडेंसी

डेटा रेजिडेंसी होस्टिंग के उन चुनिंदा निर्णयों में से एक है जिन्हें बदलना वास्तव में कठिन है, इसलिए प्लेटफ़ॉर्म इसे डिप्लॉयमेंट का केवल एक विवरण मानने के बजाय एक प्राथमिक आयाम के रूप में देखता है। ग्राहक द्वारा रेजिडेंसी का चयन प्लेसमेंट के लिए एक इनपुट होता है, साइट के विरुद्ध क्षेत्र दर्ज किया जाता है, और मिलान के लिए फ़्लीट को टैग किया जाता है। यही कारण है कि रेजिडेंसी संबंधी उत्तर महज काल्पनिक न होकर ऑडिट करने योग्य बनता है।

किरायेदारी मॉडल इसके साथ-साथ चलता है। इंजन में प्रत्येक रिकॉर्ड डेटाबेस पर लागू PostgreSQL पंक्ति-स्तरीय सुरक्षा के साथ एक संगठन का दायरा रखता है, और किरायेदारी पदानुक्रमित है — साइटों के ऊपर ग्राहक संगठन, जिनके ऊपर पुनर्विक्रेता संगठन होता है। क्षेत्र यह निर्धारित करता है कि डेटा कहाँ स्थित है; पंक्ति-स्तरीय सुरक्षा यह निर्धारित करती है कि उस तक कौन पहुँच सकता है। अनुपालन समीक्षक के लिए दोनों महत्वपूर्ण हैं और इनमें से कोई भी वैकल्पिक नहीं है।

GDPR डेटा निर्यात और निष्कासन किसी अलग से जोड़े गए तंत्र के बजाय उसी डिज़ाइन का हिस्सा हैं, और विशेषाधिकार प्राप्त व प्रशासनिक कार्रवाइयों का ऑडिट-लॉग रखा जाता है। यदि आपके खरीदार की प्रश्नावली यह पूछती है कि डेटा कहाँ रहता है, कौन इसके लिए क्वेरी कर सकता है और जब कोई डेटा विषय इसे वापस माँगता है तो क्या होता है, तो ये ऐसे प्रश्न हैं जिनका उत्तर यहाँ दिया जा सकता है।

एक स्थानीय मूल गति की कहानी का केवल आधा हिस्सा है

किसी नजदीकी क्षेत्र को चुनना मददगार होता है, लेकिन आपके विज़िटर्स जिस लेटेंसी को महसूस करते हैं उसका अधिकांश हिस्सा अनुरोध आपके मूल सर्वर तक पहुँचने से पहले ही तय हो जाता है।

  • Cloudflare हर चीज़ के आगे रहता है — CDN, WAF, DNS और DDoS सुरक्षा — ताकि कैश करने योग्य प्रतिक्रियाएं आपके मूल क्षेत्र के बजाय विज़िटर के नज़दीक एज से प्रस्तुत की जा सकें।
  • LSCache सीधे वर्कर पर ही ESI और स्मार्ट ऑटो-पर्ज के साथ सर्वर-स्तरीय फ़ुल-पेज कैश के रूप में चलता है, जिसका अर्थ है कि अधिकांश WordPress अनुरोध कभी भी PHP या MySQL तक नहीं पहुँचते हैं।
  • प्रति-साइट Redis ऑब्जेक्ट कैश एप्लिकेशन तक पहुँचने वाले अनुरोधों से बार-बार होने वाले डेटाबेस रीड्स को हटा देता है।
  • पैनल में एक नियंत्रण से और Zinn® कैश प्लगइन के माध्यम से WordPress के भीतर से दोनों परतों में पर्ज समन्वित किया जाता है, ताकि आपके प्रकाशित करने के बाद एज कॉपी और ओरिजिन कॉपी में कभी भी असंगति न हो।
  • Footprint-Free ग्राहक शीर्ष पर CDN खाता पूलों को लेयर करते हैं: साइटें हमारे खातों और आपके अपने खातों में वितरित होती हैं, जहाँ डिप्लॉयमेंट के समय लाइव खाता स्थिति से संतुलन की पुनर्गणना की जाती है।
  • हम विलंबता या थ्रूपुट का कोई बेंचमार्क प्रकाशित नहीं करते हैं, और हम यह दावा नहीं करते हैं कि कोई विशिष्ट क्षेत्र आपके दर्शकों के लिए सबसे तेज़ होगा। वह क्षेत्र चुनें जो आपके आगंतुकों और आपकी अनुपालन स्थिति के अनुरूप हो, और बाकी काम कैश लेयर्स पर छोड़ दें।

विफलता डोमेन, बैकअप और ईमानदार सीमाएं

मल्टी-रीजन का मूल्य बहुत कम रह जाता है यदि सब कुछ अभी भी एक ही नियति साझा करता है। यह आर्किटेक्चर उन हिस्सों को अलग करता है जिन्हें एक साथ विफल नहीं होना चाहिए।

कंट्रोल प्लेन और बेड़ा अलग हैं

इंजन, डेटाबेस, वर्कफ़्लो स्तर और डैशबोर्ड अपने स्वयं के Kubernetes कंट्रोल प्लेन पर चलते हैं, जो ग्राहक साइटों को सेवा देने वाले वर्कर फ़्लीट से पूरी तरह अलग हैं। कंट्रोल-प्लेन की घटना से ग्राहक साइटें डाउन नहीं होनी चाहिए, और फ़्लीट की घटना से प्लेटफ़ॉर्म डाउन नहीं होना चाहिए।

सार्वजनिक सतहें भी स्वतंत्र हैं

ग्राहक डैशबोर्ड, एडमिन कंसोल और यह मार्केटिंग साइट कंट्रोल-प्लेन क्लस्टर से स्वतंत्र रूप से Cloudflare पर तैनात हैं, ताकि प्लेटफ़ॉर्म की कोई घटना उस स्थान को भी न हटा दे जहाँ आप इसके बारे में पढ़ने जाते हैं।

स्थिति प्लेटफ़ॉर्म से बाहर है

स्थिति पृष्ठ (स्टेटस पेज) को जानबूझकर एक अलग क्षेत्र में एक अलग प्रदाता के साथ होस्ट किया गया है। जिस बुनियादी ढांचे की वह निगरानी करता है, उसी पर चलने वाला स्थिति पृष्ठ ठीक उसी समय बेकार साबित होता है जब आपको उसकी आवश्यकता होती है।

अपरिवर्तनीय, ऑफ़साइट, पृथक बैकअप

प्रत्येक साइट के बैकअप अपरिवर्तनीय और ऑफ़साइट होते हैं, जिन्हें ऑब्जेक्ट स्टोरेज में लिखा जाता है, और पुनर्स्थापना (रिस्टोर) का केवल अनुमान लगाने के बजाय उनका परीक्षण किया जाता है। फ़ाइल प्रबंधक, डोमेन, DNS, SSL और लॉग के साथ पैनल से केवल एक क्लिक में पुनर्स्थापना संभव है।

हम क्या दावा नहीं करते हैं

हम इस पृष्ठ पर सेवा-स्तर समझौते, प्रतिक्रिया समय या विलंबता के आंकड़े का दावा नहीं करते हैं — SLA शर्तें अनुबंध के अनुसार सहमत होती हैं। Footprint-Free योजनाओं से जुड़ा 99.99% का आंकड़ा अपटाइम का एक आश्वासन है, एक ऐसा लक्ष्य जिसके लिए हम निर्माण करते हैं, न कि उपलब्धता का कोई मापा गया ऐतिहासिक रिकॉर्ड।

क्षेत्र चुनना

व्यवहार में यह निर्णय चार प्रश्नों पर आधारित होता है, और अधिकांश ग्राहक एक मिनट से भी कम समय में उनके उत्तर दे देते हैं।

  • क्या आपके पास कोई संविदात्मक या विनियामक निवास संबंधी आवश्यकता है? यदि हाँ, तो यह तय करता है — GDPR दायित्वों वाले EU ग्राहक यूरोपीय संघ के भीतर एक डेटा केंद्र चुनते हैं, और जब कोई अनुबंध विशेष रूप से इसकी मांग करता है तो हमारे पास GDPR-अनुकूल EU रूट होता है।
  • आपके वे दर्शक कहाँ हैं जिनसे आप वास्तव में कमाई करते हैं? ऑर्डर फ़ॉर्म में दिए गए शहरों में से उनके सबसे नज़दीकी डेटा सेंटर को चुनें।
  • क्या आपके खरीदार की खरीद प्रक्रिया के लिए प्रमाणित अंतर्निहित प्लेटफ़ॉर्म की आवश्यकता है? यदि आपकी साइटों के अंतर्गत आने वाले बुनियादी ढांचे पर SOC 2 या ISO 27001 सत्यापन एक अनिवार्य शर्त है, तो निर्माण करने से पहले हमें बताएं और हम आपको उस क्षमता पर रखेंगे जिसके पास यह है।
  • क्या आप अपने पोर्टफोलियो को विफलता डोमेन में विभाजित करना चाहते हैं? साइटों को एक से अधिक डेटा केंद्रों में रखने से एकल-स्थान की निर्भरता समाप्त हो जाती है।
  • सुनिश्चित नहीं हैं? बिना कार्ड वाले ट्रायल से शुरुआत करें। बाद में कहीं और डिप्लॉय करने पर भी पैनल, ड्राइवर या फ़ीचर सेट में कुछ भी नहीं बदलता है।

अक्सर पूछे जाने वाले प्रश्न

क्या मैं यह चुन सकता हूँ कि मेरी साइटें किस क्षेत्र में परिनियोजित की जाएँ?

हाँ। क्षेत्र प्लेसमेंट इंजन के लिए एक इनपुट है, अलग से संसाधित किया जाने वाला कोई अनुरोध नहीं। किसी क्षेत्र को पिन करें और केवल उस क्षेत्र के लिए टैग किए गए फ़्लीट वर्कर्स ही साइट प्राप्त करने के पात्र होंगे; इसके बाद चुने गए क्षेत्र को साइट रिकॉर्ड पर संग्रहीत किया जाता है ताकि आप हमेशा यह देख सकें कि यह कहाँ चलता है। इसे अनिर्धारित छोड़ दें और साइट उस वर्कर के क्षेत्र को इनहेरिट कर लेगी जिस पर वह आती है।

आप किन क्षेत्रों में काम करते हैं?

यह होस्टिंग लाइन पर निर्भर करता है, क्योंकि प्रत्येक लाइन उसके लिए बनाई गई क्षमता पर चलती है। ऑर्डर फ़ॉर्म और प्रत्येक होस्टिंग पेज उन शहरों की सूची दिखाता है जिन्हें आप आज चुन सकते हैं, जो प्लेसमेंट इंजन से सीधे पढ़े जाते हैं, ताकि यह उत्तर कभी पुराना न हो। सख्त EU डेटा निवास के लिए, यूरोपीय संघ के अंदर एक डेटा केंद्र चुनें; जहाँ खरीद के लिए प्रमाणित अंतर्निहित प्लेटफ़ॉर्म की आवश्यकता होती है, हम उन आवश्यकताओं को पूरा करने वाली क्षमता पर स्थापित कर सकते हैं। प्रत्येक स्थान के पीछे के आपूर्तिकर्ता हमारी अपनी व्यावसायिक व्यवस्था हैं — आप स्थान चुनते हैं, विक्रेता नहीं।

क्या आपके पास SOC 2 या ISO 27001 प्रमाणन है?

नहीं — Zinn Digital® के पास आज अपने स्वयं के कोई अनुपालन प्रमाणन नहीं हैं, और हम अन्यथा संकेत नहीं देंगे। हम जो कर सकते हैं वह यह है कि आपके वर्कलोड को एक ऐसे अंतर्निहित प्लेटफ़ॉर्म पर रखें जिसके पास वे हैं, जहाँ किसी खरीदार की खरीद आपके साइटों के नीचे एक प्रमाणित प्लेटफ़ॉर्म को एक अनिवार्य आवश्यकता बनाती है। अलग से, प्लेटफ़ॉर्म के अपने नियंत्रण वास्तविक और निरीक्षण योग्य हैं: प्रति-साइट पृथक्करण, प्रत्येक किरायेदार-क्षेत्रीय तालिका पर पंक्ति-स्तरीय सुरक्षा, Vault में रखे गए रहस्य, शुरू से अंत तक TLS, और विशेषाधिकार प्राप्त कार्रवाइयों का ऑडिट लॉगिंग।

यदि मेरे द्वारा वांछित क्षेत्र में क्षमता नहीं है तो क्या होगा?

डिप्लॉय आपकी साइट को चुपचाप कहीं और ले जाने के बजाय प्लेसमेंट त्रुटि के साथ प्रत्यक्ष रूप से विफल हो जाता है। यह जानबूझकर किया गया है: चुपचाप क्षेत्राधिकार बदलने वाली साइट उस डिप्लॉय की तुलना में कहीं अधिक ख़राब परिणाम है जो रुक गया और जिसने आपको कारण बताया। उस क्षेत्र में अधिक होस्ट्स को ऑनलाइन लाकर क्षमता जोड़ी जाती है, जहाँ वे स्वयं को पंजीकृत करते हैं और तुरंत कार्य स्वीकार करना शुरू कर देते हैं।

क्या मेरी साइट उसके डेटा सेंटर से दूर स्थित विज़िटर्स के लिए धीमी होगी?

हम विलंबता बेंचमार्क प्रकाशित नहीं करते हैं और किसी विशिष्ट आंकड़े का वादा नहीं करेंगे। हम जिसकी व्याख्या कर सकते हैं वह है इसकी वास्तुकला: Cloudflare प्रत्येक साइट के अग्रभाग के रूप में कार्य करता है ताकि कैश करने योग्य प्रतिक्रियाएं विज़िटर के नजदीकी एज स्थान से प्रस्तुत की जाएं, LSCache बिना PHP या डेटाबेस को छुए वर्कर से पूर्ण पृष्ठ प्रस्तुत करता है, और प्रति-साइट Redis ऑब्जेक्ट कैश बार-बार की जाने वाली क्वेरीज़ को अवशोषित करता है। अधिकांश सामग्री साइटों के लिए इस संयोजन का अर्थ यह है कि कैश कॉन्फ़िगरेशन की तुलना में मूल क्षेत्र का महत्व बहुत कम है। यदि आपके दर्शक एक ही महाद्वीप में केंद्रित हैं, तो भी मूल क्षेत्र को वहीं रखें।

क्या मैं बाद में किसी मौजूदा साइट को किसी अन्य क्षेत्र में स्थानांतरित कर सकता हूँ?

क्षेत्र तब निर्धारित किया जाता है जब कोई साइट स्थापित की जाती है और इसे साइट रिकॉर्ड में संग्रहीत किया जाता है, इसलिए क्षेत्र बदलना एक माइग्रेशन है, न कि केवल एक टॉगल। यदि आप पहले से जानते हैं कि साइट को स्थानांतरित किया जाना है, तो निर्माण से पहले हमसे संपर्क करें — किसी लाइव पोर्टफोलियो को स्थानांतरित करने की तुलना में पहली बार में ही इसे सही स्थान पर रखना कहीं अधिक किफायती है।

मेरे बैकअप कहाँ रखे जाते हैं?

प्रति-साइट बैकअप अपरिवर्तनीय, ऑफ़साइट और सक्रिय फ़्लीट से अलग होते हैं, जिन्हें ऑब्जेक्ट स्टोरेज में लिखा जाता है जहाँ पुनर्स्थापना को केवल मान लेने के बजाय परखा जाता है, और पैनल से एक क्लिक में पुनर्स्थापित किया जा सकता है। यदि आपकी अनुपालन स्थिति के लिए बैकअप स्टोरेज का किसी विशिष्ट क्षेत्राधिकार में होना आवश्यक है, तो सीधे हमसे संपर्क करें — यह एक संविदात्मक विवरण है जिसे हम वेब पेज पर सामान्य दावा करने के बजाय प्रत्येक ग्राहक के अनुसार तय करते हैं।

क्या मैं किसी क्षेत्र के लिए प्रतिबद्ध हुए बिना इसे आज़मा सकता हूँ?

हाँ। परीक्षण अवधि 14 दिनों की है और इसके लिए कार्ड की आवश्यकता नहीं है। इसमें अधिकतम पाँच साइटों के साथ Footprint-Free Hosting शामिल है, जो यह देखने के लिए पर्याप्त है कि आपके प्रोडक्शन पोर्टफोलियो को कहाँ रखा जाना चाहिए, इसका निर्णय लेने से पहले डिप्लॉयमेंट, प्लेसमेंट और कैश लेयर्स कैसे काम करते हैं।

वहाँ से शुरुआत करें जहाँ सही लगे, ज़रूरत पड़ने पर आगे बढ़ें

बिना कार्ड के 14-दिवसीय परीक्षण शुरू करें, या पहले हमें अपनी डेटा निवास आवश्यकता बताएं और हम आपको पहली परिनियोजन से ही सही ढंग से स्थापित करेंगे।

मुफ़्त शुरू करें