Pinili bawat site
Nag-aalok ang bawat linya ng hosting ng sarili nitong hanay ng mga data center. Pumili ka ng isa kapag gumawa ka ng site, at nag-aalok lamang ang form ng order ng lungsod kung saan may espasyo ang linyang iyon ngayon.
Mga rehiyon at paninirahan ng data
Ang rehiyon ay hindi isang support ticket sa platform na ito — ito ay isang katangian ng site, na sinusunod ng placement engine tuwing may idinedeploy. Pipiliin ninyo ang data center kapag lumikha kayo ng site, mula sa mga lungsod na iniaalok ng hosting line nito ngayon, at ang bawat deploy ay napupunta sa fleet capacity sa lokasyong iyon, na mayroong global edge sa unahan nito. Inililista ng bawat hosting page ang mga lungsod na iyon, na binabasa nang live.
May dalawang bagay sa likod ng bawat lokasyon: ang worker fleet na nagpapatakbo sa inyong mga site, at ang control plane na namamahala sa mga ito. Parehong may kamalayan sa rehiyon ang dalawa. Kayo ang pipili kung aling lokasyon ang gusto ninyo; ang kapasidad sa ilalim nito ay sarili naming pagsasaayos, at sadyang gumagamit kami ng higit sa isang supplier upang walang nag-iisang supplier ang maging buong platform.
Nag-aalok ang bawat linya ng hosting ng sarili nitong hanay ng mga data center. Pumili ka ng isa kapag gumawa ka ng site, at nag-aalok lamang ang form ng order ng lungsod kung saan may espasyo ang linyang iyon ngayon.
Ang mga lungsod sa bawat page ng hosting at sa form ng order ay binabasa mula sa placement engine, kaya lumalabas ang isang bagong lokasyon sa araw na magkaroon ito ng kapasidad, at hindi iniaalok ang puno na.
Ipinapatupad ang rehiyon sa code, sa sandaling ginawa ang isang site — hindi ng isang operator na nagtatanda kung aling kahon ang gagamitin.
Ang bawat host sa fleet ay nagrerehistro sa sarili gamit ang isang region key, isang listahan ng product-line affinity, isang uri ng web-server, at isang numero ng kapasidad, pagkatapos ay kumukuha ng trabaho. Sinasala muna ng serbisyo ng paglalagay ang mga kandidato ayon sa rehiyon, pagkatapos ay sa linya ng produkto, pagkatapos ay sa bakanteng kapasidad, at pinipili ang kwalipikadong host na may pinakamababang karga.
Kung nag-pin ka ng rehiyon, tanging ang mga worker lang sa rehiyong iyon ang kwalipikado. Kung hindi mo ginawa, mamamana ng site ang rehiyon ng worker kung saan ito mapupunta at ang halagang iyon ay maiimbak sa site — kaya ang tala kung saan naroroon ang iyong data ay isang field na maaari mong basahin, hindi isang pagpapalagay.
Inaangkin ng placement ang kapasidad sa pamamagitan ng isang may-kondisyong pag-update na nagtatagumpay lamang habang aktibo pa ang worker, tumatanggap pa rin ng mga pag-deploy, at mas mababa pa sa kapasidad. Ang dalawang pag-deploy na nag-uunahan para sa huling puwang ay hindi maaaring parehong manalo, kaya hindi kailanman tahimik na nasosobrahan sa kapasidad ang isang rehiyon.
Kung walang karapat-dapat sa iyong rehiyon ang may espasyo, ang pag-deploy ay maglalabas ng error sa pagkakalagay at hihinto. Hindi ito lilipat sa ibang kontinente para maging matagumpay ang kahilingan. Ang isang nakikitang pagkabigo at pagdaragdag ng kapasidad ay mas mainam kaysa sa isang site na tahimik na lumipat ng bansa.
Ang bawat worker ay may switch na accepts-deploys. Ang paglipat nito sa drain ay nagpapahinto sa pagpasok ng mga bagong site habang ang mga umiiral nang site ay patuloy na gumagana nang hindi nagagalaw, na siyang paraan namin sa pagsasagawa ng maintenance, pag-upgrade ng hardware, at pag-decommission sa loob ng isang rehiyon nang hindi inililipat ang inyong mga workload.
Ang residency ng data ay isa sa iilang desisyon sa hosting na talagang mahirap bawiin, kaya itinuturing ito ng platform bilang isang first-class dimension sa halip na isang detalye lamang ng pag-deploy. Ang pagpili ng customer sa residency ay input para sa paglalagay, itinatala ang rehiyon para sa site, at tina-tag ang fleet upang tumugma. Ito ang dahilan kung bakit nagiging auditable ang sagot sa residency sa halip na kuwento-kuwento lamang.
Tumatakbo ang modelo ng tenancy kasabay nito. Ang bawat tala sa engine ay may saklaw ng organisasyon na may PostgreSQL row-level security na ipinapatupad sa database, at hierarchical ang tenancy — isang organisasyon ng reseller sa itaas ng mga organisasyon ng kliyente sa itaas ng mga site. Sinasagot ng rehiyon kung saan nakalagay ang data; sinasagot ng row-level security kung sino ang maaaring umabot dito. Parehong mahalaga ang mga ito sa isang tagasuri ng pagsunod at alinman ay hindi opsyonal.
Ang pag-export at pagbura ng data ng GDPR ay bahagi ng parehong disenyo sa halip na isang idinugtong lamang na proseso, at ang mga pribilehiyo at administratibong pagkilos ay naka-audit log. Kung itinatanong sa talatanungan ng iyong mamimili kung saan naninirahan ang data, sino ang maaaring mag-query nito, at kung ano ang mangyayari kapag hiniling ito pabalik ng isang paksa, ang mga iyon ay masasagot na mga katanungan dito.
Nakatutulong ang pagpili ng kalapit na rehiyon, ngunit ang karamihan sa latency na nararanasan ng inyong mga bisita ay napagpapasyahan na bago pa man makarating ang isang kahilingan sa inyong pinagmulan.
Napakaliit ng halaga ng multi-region kung ang lahat ay magkakaroon pa rin ng iisang kapalaran. Hinihiwalay ng arkitektura ang mga bahaging hindi dapat magkasabay na mabigo.
Ang engine, database, workflow layer, at mga dashboard ay tumatakbo sa kanilang sariling Kubernetes control plane, ganap na hiwalay sa worker fleet na nagsisilbi sa mga site ng customer. Ang isang insidente sa control-plane ay hindi dapat magpabagsak sa mga site ng customer, at ang isang insidente sa fleet ay hindi dapat magpabagsak sa platform.
Ang customer dashboard, ang admin console at ang marketing site na ito ay naka-deploy sa Cloudflare nang hiwalay sa control-plane cluster, kaya ang isang insidente sa platform ay hindi mag-aalis sa lugar na pupuntahan ninyo upang magbasa tungkol dito.
Sadyang hino-host ang status page sa ibang provider sa ibang rehiyon. Ang isang status page na tumatakbo sa imprastraktura na binabantayan nito ay walang silbi sa mismong sandali na kailangan mo ito.
Ang mga backup bawat site ay hindi nababago at nasa labas ng site, nakasulat sa imbakan ng bagay, at ang mga pagpapanumbalik ay sinusubukan sa halip na ipagpalagay lamang. Ang mga pagpapanumbalik ay isang-pindot lang mula sa panel kasama ng tagapamahala ng file, mga domain, DNS, SSL, at mga log.
Hindi kami nagpapahayag ng kasunduan sa antas ng serbisyo, oras ng pagtugon, o bilang ng latency sa pahinang ito — ang mga tuntunin ng SLA ay pinagkakasunduan bawat kontrata. Ang 99.99% na bilang na nakalakip sa mga Footprint-Free na plano ay isang katiyakan ng uptime, isang layunin na aming pinagsisikapang maabot, hindi isang nasusukat na talaan ng historikal na availability.
Sa pagsasagawa, ang desisyon ay nakasalalay sa apat na katanungan, at karamihan sa mga customer ay sinasagot ang mga ito sa loob ng wala pang isang minuto.
Oo. Ang rehiyon ay isang input sa placement engine, hindi isang kahilingan na pinangangasiwaan nang hiwalay. I-pin ang isang rehiyon at mga fleet worker lamang na naka-tag para sa rehiyong iyon ang magiging kwalipikadong tumanggap sa site; ang napiling rehiyon ay ise-save sa talaan ng site upang palagi ninyong mabasa kung saan ito tumatakbo. Iwanan itong hindi nakatakda at mamamana ng site ang rehiyon ng worker kung saan ito mapupunta.
Depende ito sa linya ng hosting, dahil tumatakbo ang bawat linya sa kapasidad na binuo para rito. Nakalista sa form ng order at sa bawat pahina ng hosting ang mga lungsod na maaari mong piliin ngayon, na direktang binabasa mula sa placement engine, kaya hindi kailanman naluluma ang sagot na ito. Para sa mahigpit na paninirahan sa EU, pumili ng data center sa loob ng European Union; kung saan nangangailangan ang pagbili ng sertipikadong pinagbabatayang platform, maaari kaming maglagay sa kapasidad na nakakatugon sa mga kinakailangang iyon. Ang mga supplier sa likod ng bawat lokasyon ay aming sariling komersyal na pagsasaayos — pipiliin mo ang lokasyon, hindi ang vendor.
Hindi — Ang Zinn Digital® ay walang sariling mga sertipikasyon sa pagsunod sa ngayon, at hindi namin ipapahiwatig ang kabaligtaran. Ang maaari naming gawin ay ilagay ang iyong workload sa isang pinagbabatayang platform na nagtataglay ng mga ito, kung saan ginagawang mahigpit na kinakailangan ng pagbili ng isang mamimili ang isang sertipikadong platform sa ilalim ng iyong mga site. Bukod pa rito, ang sariling mga kontrol ng platform ay totoo at maaaring siyasatin: paghihiwalay bawat site, seguridad sa antas ng hilera sa bawat talahanayan na saklaw ng nangungupahan, mga lihim na hawak sa Vault, TLS sa kabuuan, at pag-log ng audit sa mga may pribilehiyong pagkilos.
Hayagang nabibigo ang pag-deploy nang may error sa pagkakalagay sa halip na tahimik na ilipat ang inyong site sa ibang lugar. Sinasadya iyon: ang isang site na tahimik na nagpalit ng hurisdiksyon ay malayong mas masamang resulta kaysa sa isang pag-deploy na huminto at nagpaliwanag sa inyo kung bakit. Nadaragdagan ang kapasidad sa pamamagitan ng pagdadala ng mas maraming host online sa rehiyong iyon, kung saan inirerehistro nila ang kanilang sarili at agad na nagsisimulang tumanggap ng gawain.
Hindi kami naglalathala ng mga benchmark ng latency at hindi mangangako ng isang partikular na numero. Ang mailalarawan namin ay ang arkitektura: Nasa harap ng bawat site ang Cloudflare upang ang mga tugong puwedeng i-cache ay maihatid mula sa isang lokasyon sa edge na malapit sa bisita, naghahatid ang LSCache ng buong mga pahina mula sa worker nang hindi ginagalaw ang PHP o ang database, at sinisipsip ng isang Redis object cache bawat site ang mga paulit-ulit na query. Para sa karamihan ng mga content site, nangangahulugan ang kumbinasyong iyan na mas hindi gaanong mahalaga ang rehiyon ng pinagmulan kaysa sa pagsasaayos ng cache. Kung ang inyong audience ay nakatipon sa iisang kontinente, ilagay pa rin doon ang pinagmulan.
Itinatakda ang rehiyon kapag inilagay ang isang site at nakaimbak ito sa tala ng site, kaya ang pagpapalit ng rehiyon ay isang migrasyon sa halip na simpleng pag-toggle. Makipag-ugnayan sa amin bago ka magtayo kung alam mo nang may paparating na paglipat — higit na mas mura ang maglagay nang tama sa unang pagkakataon kaysa maglipat ng isang live na portfolio.
Ang mga backup bawat site ay hindi nababago, offsite, at nakahiwalay sa tumatakbong fleet, nakasulat sa imbakan ng bagay kung saan sinusuri ang mga pagpapanumbalik sa halip na ipagpalagay lang, at maaaring maibalik sa isang click mula sa panel. Kung ang inyong katayuan sa pagsunod ay nangangailangan na ang imbakan ng backup ay nasa isang partikular na hurisdiksyon, direktang makipag-ugnayan sa amin — iyan ay isang detalyeng kontraktwal na pinagkakasunduan namin bawat customer sa halip na isang pangkalahatang pahayag sa isang web page.
Oo. Ang trial ay 14 na araw at hindi kailangan ng card. Sinasaklaw nito ang Footprint-Free Hosting na may hanggang limang site, na sapat upang makita kung paano gumagana ang mga deploy, placement, at mga cache layer bago kayo magpasya kung saan dapat manatili ang inyong production portfolio.
Magsimula ng 14-araw na pagsubok nang walang kailangan na card, o sabihin muna sa amin ang inyong kinakailangan sa residency at ilalagay namin kayo nang tama mula sa unang pag-deploy.
Magsimula nang libre