प्रति साइट चुना गया
प्रत्येक होस्टिंग लाइन डेटा केंद्रों का अपना सेट प्रदान करती है। साइट बनाते समय आप एक का चयन करते हैं, और ऑर्डर फॉर्म केवल वही शहर दिखाता है जहाँ उस लाइन में आज जगह उपलब्ध है।
क्षेत्र और डेटा रेजीडेंसी
इस प्लेटफ़ॉर्म पर क्षेत्र (रीजन) कोई सहायता टिकट नहीं है — यह साइट की एक विशेषता है, जिसे हर बार कुछ डिप्लॉय किए जाने पर प्लेसमेंट इंजन द्वारा सम्मानित किया जाता है। जब आप कोई साइट बनाते हैं, तो आप उस डेटा सेंटर को चुनते हैं जिसे उसकी होस्टिंग लाइन आज पेश करती है, और प्रत्येक डिप्लॉय उस स्थान पर बेड़े की क्षमता पर जाता है, जिसके आगे एक वैश्विक एज होता है। प्रत्येक होस्टिंग पृष्ठ उन शहरों को लाइव पढ़कर सूचीबद्ध करता है।
प्रत्येक स्थान के पीछे दो चीज़ें होती हैं: वर्कर फ़्लीट जो आपकी साइटों को चलाता है, और कंट्रोल प्लेन जो उनका प्रबंधन करता है। दोनों क्षेत्र-जागरूक हैं। आप कौन सा स्थान चुनते हैं यह आपकी पसंद है; इसके अंतर्गत क्षमता हमारी अपनी व्यवस्था है, और हम जानबूझकर एक से अधिक आपूर्तिकर्ताओं का उपयोग करते हैं ताकि कोई एक आपूर्तिकर्ता ही पूरा प्लेटफ़ॉर्म न बन जाए।
प्रत्येक होस्टिंग लाइन डेटा केंद्रों का अपना सेट प्रदान करती है। साइट बनाते समय आप एक का चयन करते हैं, और ऑर्डर फॉर्म केवल वही शहर दिखाता है जहाँ उस लाइन में आज जगह उपलब्ध है।
प्रत्येक होस्टिंग पृष्ठ और ऑर्डर फ़ॉर्म पर दिखने वाले शहर प्लेसमेंट इंजन से पढ़े जाते हैं, इसलिए क्षमता उपलब्ध होने के दिन ही नया स्थान दिखाई देने लगता है, और पूर्ण क्षमता वाले स्थान की पेशकश नहीं की जाती है।
साइट बनाए जाने के क्षण में ही कोड द्वारा क्षेत्र लागू किया जाता है — न कि किसी ऑपरेटर द्वारा यह याद रखने से कि किस बॉक्स का उपयोग करना है।
फ्लीट का प्रत्येक होस्ट एक क्षेत्र कुंजी, एक उत्पाद-पंक्ति आत्मीयता सूची, एक वेब-सर्वर प्रकार और एक क्षमता आंकड़े के साथ खुद को पंजीकृत करता है, फिर काम लेता है। प्लेसमेंट सेवा उम्मीदवारों को पहले क्षेत्र, फिर उत्पाद-पंक्ति, फिर खाली क्षमता के आधार पर फ़िल्टर करती है, और सबसे कम लोड वाले योग्य होस्ट को चुनती है।
यदि आपने कोई क्षेत्र पिन किया है, तो केवल उस क्षेत्र के वर्कर ही योग्य हैं। यदि आपने ऐसा नहीं किया है, तो साइट उस वर्कर के क्षेत्र को इनहेरिट करती है जिस पर वह आती है और वह मान साइट पर संग्रहीत हो जाता है — इसलिए आपका डेटा कहाँ रहता है इसका रिकॉर्ड एक फ़ील्ड है जिसे आप पढ़ सकते हैं, कोई अनुमान नहीं।
प्लेसमेंट एक सशर्त अपडेट के साथ क्षमता का दावा करता है जो केवल तभी सफल होता है जब वर्कर अभी भी सक्रिय हो, अभी भी डिप्लॉय स्वीकार कर रहा हो और अभी भी क्षमता से कम हो। अंतिम स्लॉट के लिए प्रतिस्पर्धा करने वाले दो डिप्लॉय दोनों सफल नहीं हो सकते, इसलिए किसी भी क्षेत्र में कभी भी चुपचाप क्षमता से अधिक आवंटन नहीं होता है।
यदि आपके क्षेत्र में किसी भी योग्य संसाधन में स्थान नहीं है, तो डिप्लॉय एक प्लेसमेंट त्रुटि उत्पन्न करता है और रुक जाता है। यह अनुरोध को सफल बनाने के लिए किसी अन्य महाद्वीप पर नहीं जाता है। बिना बताए देश बदल लेने वाली साइट की तुलना में एक स्पष्ट विफलता और क्षमता विस्तार कहीं बेहतर है।
प्रत्येक worker में एक accepts-deploys स्विच होता है। इसे drain पर करने से नई साइटों का आना बंद हो जाता है जबकि मौजूदा साइटें बिना किसी रुकावट के चलती रहती हैं, जिससे हम आपके वर्कलोड को स्थानांतरित किए बिना किसी क्षेत्र के भीतर रखरखाव, हार्डवेयर रिफ्रेश और डिकमीशनिंग का कार्य करते हैं।
डेटा रेजिडेंसी होस्टिंग के उन चुनिंदा निर्णयों में से एक है जिन्हें बदलना वास्तव में कठिन है, इसलिए प्लेटफ़ॉर्म इसे डिप्लॉयमेंट का केवल एक विवरण मानने के बजाय एक प्राथमिक आयाम के रूप में देखता है। ग्राहक द्वारा रेजिडेंसी का चयन प्लेसमेंट के लिए एक इनपुट होता है, साइट के विरुद्ध क्षेत्र दर्ज किया जाता है, और मिलान के लिए फ़्लीट को टैग किया जाता है। यही कारण है कि रेजिडेंसी संबंधी उत्तर महज काल्पनिक न होकर ऑडिट करने योग्य बनता है।
किरायेदारी मॉडल इसके साथ-साथ चलता है। इंजन में प्रत्येक रिकॉर्ड डेटाबेस पर लागू PostgreSQL पंक्ति-स्तरीय सुरक्षा के साथ एक संगठन का दायरा रखता है, और किरायेदारी पदानुक्रमित है — साइटों के ऊपर ग्राहक संगठन, जिनके ऊपर पुनर्विक्रेता संगठन होता है। क्षेत्र यह निर्धारित करता है कि डेटा कहाँ स्थित है; पंक्ति-स्तरीय सुरक्षा यह निर्धारित करती है कि उस तक कौन पहुँच सकता है। अनुपालन समीक्षक के लिए दोनों महत्वपूर्ण हैं और इनमें से कोई भी वैकल्पिक नहीं है।
GDPR डेटा निर्यात और निष्कासन किसी अलग से जोड़े गए तंत्र के बजाय उसी डिज़ाइन का हिस्सा हैं, और विशेषाधिकार प्राप्त व प्रशासनिक कार्रवाइयों का ऑडिट-लॉग रखा जाता है। यदि आपके खरीदार की प्रश्नावली यह पूछती है कि डेटा कहाँ रहता है, कौन इसके लिए क्वेरी कर सकता है और जब कोई डेटा विषय इसे वापस माँगता है तो क्या होता है, तो ये ऐसे प्रश्न हैं जिनका उत्तर यहाँ दिया जा सकता है।
किसी नजदीकी क्षेत्र को चुनना मददगार होता है, लेकिन आपके विज़िटर्स जिस लेटेंसी को महसूस करते हैं उसका अधिकांश हिस्सा अनुरोध आपके मूल सर्वर तक पहुँचने से पहले ही तय हो जाता है।
मल्टी-रीजन का मूल्य बहुत कम रह जाता है यदि सब कुछ अभी भी एक ही नियति साझा करता है। यह आर्किटेक्चर उन हिस्सों को अलग करता है जिन्हें एक साथ विफल नहीं होना चाहिए।
इंजन, डेटाबेस, वर्कफ़्लो स्तर और डैशबोर्ड अपने स्वयं के Kubernetes कंट्रोल प्लेन पर चलते हैं, जो ग्राहक साइटों को सेवा देने वाले वर्कर फ़्लीट से पूरी तरह अलग हैं। कंट्रोल-प्लेन की घटना से ग्राहक साइटें डाउन नहीं होनी चाहिए, और फ़्लीट की घटना से प्लेटफ़ॉर्म डाउन नहीं होना चाहिए।
ग्राहक डैशबोर्ड, एडमिन कंसोल और यह मार्केटिंग साइट कंट्रोल-प्लेन क्लस्टर से स्वतंत्र रूप से Cloudflare पर तैनात हैं, ताकि प्लेटफ़ॉर्म की कोई घटना उस स्थान को भी न हटा दे जहाँ आप इसके बारे में पढ़ने जाते हैं।
स्थिति पृष्ठ (स्टेटस पेज) को जानबूझकर एक अलग क्षेत्र में एक अलग प्रदाता के साथ होस्ट किया गया है। जिस बुनियादी ढांचे की वह निगरानी करता है, उसी पर चलने वाला स्थिति पृष्ठ ठीक उसी समय बेकार साबित होता है जब आपको उसकी आवश्यकता होती है।
प्रत्येक साइट के बैकअप अपरिवर्तनीय और ऑफ़साइट होते हैं, जिन्हें ऑब्जेक्ट स्टोरेज में लिखा जाता है, और पुनर्स्थापना (रिस्टोर) का केवल अनुमान लगाने के बजाय उनका परीक्षण किया जाता है। फ़ाइल प्रबंधक, डोमेन, DNS, SSL और लॉग के साथ पैनल से केवल एक क्लिक में पुनर्स्थापना संभव है।
हम इस पृष्ठ पर सेवा-स्तर समझौते, प्रतिक्रिया समय या विलंबता के आंकड़े का दावा नहीं करते हैं — SLA शर्तें अनुबंध के अनुसार सहमत होती हैं। Footprint-Free योजनाओं से जुड़ा 99.99% का आंकड़ा अपटाइम का एक आश्वासन है, एक ऐसा लक्ष्य जिसके लिए हम निर्माण करते हैं, न कि उपलब्धता का कोई मापा गया ऐतिहासिक रिकॉर्ड।
व्यवहार में यह निर्णय चार प्रश्नों पर आधारित होता है, और अधिकांश ग्राहक एक मिनट से भी कम समय में उनके उत्तर दे देते हैं।
हाँ। क्षेत्र प्लेसमेंट इंजन के लिए एक इनपुट है, अलग से संसाधित किया जाने वाला कोई अनुरोध नहीं। किसी क्षेत्र को पिन करें और केवल उस क्षेत्र के लिए टैग किए गए फ़्लीट वर्कर्स ही साइट प्राप्त करने के पात्र होंगे; इसके बाद चुने गए क्षेत्र को साइट रिकॉर्ड पर संग्रहीत किया जाता है ताकि आप हमेशा यह देख सकें कि यह कहाँ चलता है। इसे अनिर्धारित छोड़ दें और साइट उस वर्कर के क्षेत्र को इनहेरिट कर लेगी जिस पर वह आती है।
यह होस्टिंग लाइन पर निर्भर करता है, क्योंकि प्रत्येक लाइन उसके लिए बनाई गई क्षमता पर चलती है। ऑर्डर फ़ॉर्म और प्रत्येक होस्टिंग पेज उन शहरों की सूची दिखाता है जिन्हें आप आज चुन सकते हैं, जो प्लेसमेंट इंजन से सीधे पढ़े जाते हैं, ताकि यह उत्तर कभी पुराना न हो। सख्त EU डेटा निवास के लिए, यूरोपीय संघ के अंदर एक डेटा केंद्र चुनें; जहाँ खरीद के लिए प्रमाणित अंतर्निहित प्लेटफ़ॉर्म की आवश्यकता होती है, हम उन आवश्यकताओं को पूरा करने वाली क्षमता पर स्थापित कर सकते हैं। प्रत्येक स्थान के पीछे के आपूर्तिकर्ता हमारी अपनी व्यावसायिक व्यवस्था हैं — आप स्थान चुनते हैं, विक्रेता नहीं।
नहीं — Zinn Digital® के पास आज अपने स्वयं के कोई अनुपालन प्रमाणन नहीं हैं, और हम अन्यथा संकेत नहीं देंगे। हम जो कर सकते हैं वह यह है कि आपके वर्कलोड को एक ऐसे अंतर्निहित प्लेटफ़ॉर्म पर रखें जिसके पास वे हैं, जहाँ किसी खरीदार की खरीद आपके साइटों के नीचे एक प्रमाणित प्लेटफ़ॉर्म को एक अनिवार्य आवश्यकता बनाती है। अलग से, प्लेटफ़ॉर्म के अपने नियंत्रण वास्तविक और निरीक्षण योग्य हैं: प्रति-साइट पृथक्करण, प्रत्येक किरायेदार-क्षेत्रीय तालिका पर पंक्ति-स्तरीय सुरक्षा, Vault में रखे गए रहस्य, शुरू से अंत तक TLS, और विशेषाधिकार प्राप्त कार्रवाइयों का ऑडिट लॉगिंग।
डिप्लॉय आपकी साइट को चुपचाप कहीं और ले जाने के बजाय प्लेसमेंट त्रुटि के साथ प्रत्यक्ष रूप से विफल हो जाता है। यह जानबूझकर किया गया है: चुपचाप क्षेत्राधिकार बदलने वाली साइट उस डिप्लॉय की तुलना में कहीं अधिक ख़राब परिणाम है जो रुक गया और जिसने आपको कारण बताया। उस क्षेत्र में अधिक होस्ट्स को ऑनलाइन लाकर क्षमता जोड़ी जाती है, जहाँ वे स्वयं को पंजीकृत करते हैं और तुरंत कार्य स्वीकार करना शुरू कर देते हैं।
हम विलंबता बेंचमार्क प्रकाशित नहीं करते हैं और किसी विशिष्ट आंकड़े का वादा नहीं करेंगे। हम जिसकी व्याख्या कर सकते हैं वह है इसकी वास्तुकला: Cloudflare प्रत्येक साइट के अग्रभाग के रूप में कार्य करता है ताकि कैश करने योग्य प्रतिक्रियाएं विज़िटर के नजदीकी एज स्थान से प्रस्तुत की जाएं, LSCache बिना PHP या डेटाबेस को छुए वर्कर से पूर्ण पृष्ठ प्रस्तुत करता है, और प्रति-साइट Redis ऑब्जेक्ट कैश बार-बार की जाने वाली क्वेरीज़ को अवशोषित करता है। अधिकांश सामग्री साइटों के लिए इस संयोजन का अर्थ यह है कि कैश कॉन्फ़िगरेशन की तुलना में मूल क्षेत्र का महत्व बहुत कम है। यदि आपके दर्शक एक ही महाद्वीप में केंद्रित हैं, तो भी मूल क्षेत्र को वहीं रखें।
क्षेत्र तब निर्धारित किया जाता है जब कोई साइट स्थापित की जाती है और इसे साइट रिकॉर्ड में संग्रहीत किया जाता है, इसलिए क्षेत्र बदलना एक माइग्रेशन है, न कि केवल एक टॉगल। यदि आप पहले से जानते हैं कि साइट को स्थानांतरित किया जाना है, तो निर्माण से पहले हमसे संपर्क करें — किसी लाइव पोर्टफोलियो को स्थानांतरित करने की तुलना में पहली बार में ही इसे सही स्थान पर रखना कहीं अधिक किफायती है।
प्रति-साइट बैकअप अपरिवर्तनीय, ऑफ़साइट और सक्रिय फ़्लीट से अलग होते हैं, जिन्हें ऑब्जेक्ट स्टोरेज में लिखा जाता है जहाँ पुनर्स्थापना को केवल मान लेने के बजाय परखा जाता है, और पैनल से एक क्लिक में पुनर्स्थापित किया जा सकता है। यदि आपकी अनुपालन स्थिति के लिए बैकअप स्टोरेज का किसी विशिष्ट क्षेत्राधिकार में होना आवश्यक है, तो सीधे हमसे संपर्क करें — यह एक संविदात्मक विवरण है जिसे हम वेब पेज पर सामान्य दावा करने के बजाय प्रत्येक ग्राहक के अनुसार तय करते हैं।
हाँ। परीक्षण अवधि 14 दिनों की है और इसके लिए कार्ड की आवश्यकता नहीं है। इसमें अधिकतम पाँच साइटों के साथ Footprint-Free Hosting शामिल है, जो यह देखने के लिए पर्याप्त है कि आपके प्रोडक्शन पोर्टफोलियो को कहाँ रखा जाना चाहिए, इसका निर्णय लेने से पहले डिप्लॉयमेंट, प्लेसमेंट और कैश लेयर्स कैसे काम करते हैं।
बिना कार्ड के 14-दिवसीय परीक्षण शुरू करें, या पहले हमें अपनी डेटा निवास आवश्यकता बताएं और हम आपको पहली परिनियोजन से ही सही ढंग से स्थापित करेंगे।
मुफ़्त शुरू करें