Paghihiwalay bawat site
Ang paghihiwalay ang pagkakaiba sa pagitan ng isang insidente at ng isang outage. Ang bawat site na aming hino-host ay tumatakbo sa loob ng isang kernel-level na CloudLinux LVE cage na may sarili nitong mga limitasyon sa CPU, RAM, IO, at proseso, sarili nitong CageFS filesystem view, sarili nitong bersyon ng PHP, at sarili nitong database throttle. Ang isang site na inaatake, nakompromiso, o nagpapatakbo lamang ng isang napakabigat na query ay pinipigilan kung saan ito naroroon — at ang baseline ng paghihiwalay ay kasama sa bawat plano, hindi ibinebenta sa inyo bilang isang upgrade. Availability: ang per-site database throttling at per-site resource statistics ay kasalukuyang aktibong binubuo at hindi pa magagamit. Ang lahat ng iba pang inilarawan dito ay live na ngayon.
Tumatakbo ang fleet ng worker sa CloudLinux OS, na nagtutulak sa multi-tenancy pababa sa kernel. Ang bawat site ay nakakakuha ng isang Lightweight Virtual Environment — isang LVE — na isang mahigpit na hangganan sa halip na isang magalang na kumbensyon lamang. Walang anumang ginagawa ng isang site sa loob ng kulungan nito ang maaaring gastusin mula sa badyet ng iba.
Limitado ng LVE ang CPU, RAM, IO, IOPS, mga proseso, at mga entry-process para sa bawat site nang magkakahiwalay. Kapag lumampas ang isang site sa limitasyon nito, pinapabagal ito sa loob ng sarili nitong cage — itinatala ang error laban sa site na iyon, at patuloy na gumagana nang hindi naaapektuhan ang mga katabing site.
Ang isang plugin na naipit sa isang loop, isang hindi maayos na naisulat na cron job, o isang crawler na labis na nagkakarga sa isang endpoint ay unang tatama sa mga limitasyon ng sariling proseso at entry-process ng site. Hindi maaaring basta na lamang ubusin ng isang site ang buong makina.
Dahil may limitasyon ang mga entry-process sa bawat cage, ang baha ng trapiko na nakadirekta sa isang site ay hindi maaaring magbukas ng walang limitasyong gawain sa host. Ang pag-throttle ng koneksyon at kahilingan ng LiteSpeed at ang network firewall ng Imunify360 ay nakalagay sa unahan nito, kaya ang pag-atake ay nananatiling problema lamang ng target.
Itinatala ang bawat fault ng LVE bawat site at dumadaloy sa policy engine ng platform, na maaaring maghigpit o magluwag ng mga limitasyon nang awtomatiko. Nakikita mo kung bakit pinabagal ang isang site, at kung kailan — unti-unti, nababawi, at naka-log.
Pinipigilan ng paghihiwalay ng resource ang isang site na maging maingay. Pinipigilan ito ng paghihiwalay ng filesystem na maging pakialamero. Nagbibigay ang CageFS sa bawat nangungupahan ng pribado at limitadong pagtingin sa makina.
Sa ilalim ng CageFS, ang isang tenant ay nakakakita lamang ng sarili nitong mga file at ng isang minimal at nalinis na hanay ng mga system binary — at hindi makakakita ng iba pang tenant, ng mga site ng ibang tenant, o ng mga sensitibong file ng system. Ang karaniwang failure mode sa shared hosting, kung saan ang isang nakompromisong account ay nagiging posisyon para mabasa ang bawat iba pang account sa server, ay ganap na pinipigilan sa antas ng kernel.
Pinakamahalaga ito sa araw na may magkamali. Kung makompromiso ang isang site — sa pamamagitan ng lumang plugin, ninakaw na credential, o mahinang tema — CageFS ang nagpapanatili sa lawak ng pinsala sa nag-iisang cage na iyon. Sinasadya ang mga salitang ginamit sa aming detalye ng seguridad: Nililimitahan ng CageFS ang mga paglabag. Ang pagpigil ang tapat na pahayag, at ito ang nagpapasya kung ang isang insidente ay paglilinis ng iisang site o ng buong fleet.
Pinatitibay ng mga backup ang parehong hangganan. Ang mga backup sa bawat site ay hindi nababago, offsite, at nakahiwalay sa tumatakbong fleet, na may mga nasubukang pagpapanumbalik, kaya maging ang pinakamasamang sitwasyon ng pagka-kompromiso sa isang site ay may malinis at independiyenteng landas sa pagbawi na hindi nakadepende sa estado ng makina kung saan ito dating tumatakbo.
Kalahati pa lamang ng istorya ang paghihiwalay sa web-tier. Sa isang fleet ng WordPress, ang bagay na madalas na nagpapabagal sa isang server ay ang mga query ng isang site, hindi ang trapiko ng isang site. Tahasang pinangangasiwaan iyon.
Nililimitahan ng CloudLinux MySQL Governor ang paggamit ng database bawat site, kaya hindi mapapabagal ng mabibigat na query ng isang site ang server para sa iba pa. Ito ang kontrol laban sa pagbagal, at tumatakbo ito mapansin man o hindi ng maingay na site na pinipigilan ito.
Tumatakbo ang fleet sa MariaDB (o Percona), na pinili para sa mga workload ng WordPress sa halip na minana bilang default, kung saan ang Governor ang nagsisilbing per-tenant fairness layer sa ibabaw nito.
Ang bawat-site na Redis object cache ay sumasipsip ng mga paulit-ulit na pagbasa bago makarating ang mga ito sa database, na nagpapababa sa presyur na kailangang timbangin ng Governor sa simula pa lang. Ang pag-cache at paghihiwalay ay gumagana bilang isang sistema.
Ang CloudLinux alt-PHP ay nagbibigay sa bawat site ng sarili nitong tagapili ng bersyon ng PHP, sarili nitong mga extension (imagick, gd, redis, at iba pa), at sarili nitong mga pinatibay na setting — kung saan ang mga manggagawa ng LSAPI ay nalilimitahan ng mga limitasyon sa LVE ng site na iyon, kaya ang concurrency ng PHP ay bahagi ng hawla sa halip na pagtakas mula rito.
Tinutukoy ng paghihiwalay kung hanggang saan kakalat ang isang problema. Tinutukoy ng pagpapatupad kung ano ang susunod na mangyayari. Pinalitan namin ang biglaang pag-suspend na on/off ng isang state machine, na pinapagana ng matitibay na daloy ng trabaho at ipinapatupad sa worker sa pamamagitan ng LiteSpeed, LVE, at Imunify.
Ang isolation ay hindi isang feature ng plano na lumalabas nang tatlong antas pataas. Ito ay isang katangian ng substrate, kaya pareho ito kung nagpapatakbo ka man ng isang WooCommerce store o dalawang libong network site.
Tumatakbo ang mga bulk at PBN network sa parehong LVE at CageFS substrate, kasama ang footprint-aware na pag-ikot ng CDN account at static-HTML na paghahatid. Ang paghihiwalay ang nagpapanatiling ligtas sa densidad: nagbabahagi ang mga site ng fleet nang hindi nagbabahagi ng kapalaran.
Ang mga pinamamahalaang WordPress, WooCommerce, PHP, static, at Node na site ay nakakakuha ng parehong cages at ganap na self-service — ang inyong sariling bersyon at mga extension ng PHP, Redis object cache, staging, at push-to-live.
Para sa mga workload na nangangailangan ng mas matibay na hangganan kaysa sa default na na-optimize para sa density, iniaalok ang ganap na container-per-site isolation bilang isang provisioning-driver variant: parehong engine, parehong control plane, magkaibang placement, na may mas mataas na overhead.
Kasama ang paghihiwalay ng LVE at CageFS, ang maagap na WAF, at pag-scan ng malware para sa bawat customer, dahil ang isang nahawaan o hindi makontrol na site ay nagbabanta sa mga kapitbahay nito at sa reputasyon ng aming IP. Ang paglilinis ng malware sa isang click at mga advanced na antas ng proteksyon ay mga bayad na add-on — ang baseline ay hindi.
Ang komersyal na tukso sa hosting ay ang pagbebenta ng seguridad nang patingi-tingi ayon sa antas: ilagay ang mga nagtitipid na kustomer sa isang shared box na may maluluwag na limitasyon, at singilin ang mga may malasakit sa pagkakaroon ng hangganan. Hindi namin ito ginagawa, dahil ang kustomer na hindi nagbayad para sa paghihiwalay ay siya mismong magiging sanhi ng insidente para sa lahat kapag nakompromiso ang kanyang website.
Nagho-host kami ng higit sa 700,000 site sa buong mundo, sa isang fleet kung saan ang density ang buong proposisyong pang-ekonomiya. Gagana lamang iyon kung ang isolation sa ilalim nito ay walang kondisyon. Ang mga cage sa antas ng kernel, pribadong pagtingin sa filesystem, throttling ng database bawat site, at PHP bawat site ang halaga ng pagpapatakbo sa ganoong sukat nang walang pinagsasaluhang kapalaran — kaya naka-on ang mga ito para sa lahat, sa bawat plano, mula sa unang site na ide-deploy ninyo.
Ang resulta ay isang platform na kumikilos nang maaasahan kahit sa masasamang araw ng iba. Sa likod nito ay may 99.99% na garantiya sa uptime, hindi nababagong mga offsite backup para sa bawat site na may mga nasubukang pag-restore, at kumpletong audit trail ng bawat aksyon sa pagpapatupad na isinagawa sa inyong mga site.
Ang isolation ay partikular na idinisenyo upang pigilan iyan. Nililimitahan ng LVE ang CPU, RAM, IO, IOPS at mga proseso bawat site, kinokontrol ng MySQL Governor ang paggamit ng database bawat site, at ang mga worker ng LSAPI ay nakapaloob sa sariling cage ng site — kaya ang biglaang pagtaas ng trapiko o mabigat na query load ng isang kapitbahay ay pinipigilan laban sa kanilang limitasyon, hindi sa inyo. Bawat error ay naitatala bawat site, at awtomatikong mapapahigpit ng policy engine ang mga limitasyon ng isang maingay na site.
Ang tapat na sagot ay pagpigil sa halip na isang garantiya. Nagbibigay ang CageFS sa bawat tenant ng nakahiwalay na view ng filesystem — ang isang nakompromisong tenant ay hindi makakakita ng ibang mga tenant, ng kanilang mga site, o ng mga sensitibong file ng system — at ang isang kumpirmadong kaso ng malware o phishing ay naglilipat sa site na iyon sa quarantine: offline, naka-lock ang mga file, walang pagpapatupad, nakahiwalay para sa forensics. Iyan ang naglilimita sa pinsala. Kasabay nito, nagpapatakbo kami ng pag-scan ng malware at proactive na WAF sa bawat site, kasama ang hindi nababagong offsite backup bawat site na may nasubukang pag-restore, upang ang pagbawi ay hindi kailanman nakadepende sa estado ng apektadong makina.
Kasama ito sa bawat plano. Ang paghihiwalay gamit ang LVE at CageFS, ang maagap na WAF, at ang pag-scan ng malware ay baseline para sa bawat customer, dahil ang isang nahawaan o nagwawalang site ay nagbabanta sa mga kapitbahay nito at sa reputasyon ng aming IP — hindi makatwirang gawin namin itong opsyonal. Ang ibinebenta bilang add-on ay ang isang-click na paglilinis at remediation ng malware, at mga advanced na antas ng proteksyon tulad ng pinahusay na mga panuntunan sa WAF, prayoridad na pag-scan, pamamahala ng bot, at mas matataas na antas ng DDoS.
Ito ay nililimitahan (throttled) sa loob ng sarili nitong cage sa halip na tuluyang patayin. Ang pagka-throttle ay nangangahulugang mas mahigpit na mga limitasyon sa LVE at rate limiting habang ang site ay nananatiling online at gumagana, at awtomatiko itong bumabalik sa dati kapag naresolba na ang sanhi. Aabisuhan kayo kalakip ang dahilan, nakatala ang pagbabagong ito kasama ang mga ebidensya, at maaari itong iapela. Kung ang karga ay dulot ng tunay na paglago sa halip na isang sira, ang solusyon ay isang mas malaking plan, hindi ang permanenteng throttle.
Hindi — ang isang suspendidong site ay nagpapakita ng isang may-tatak at partikular-sa-dahilan na holding page (pagsingil, pagpapanatili, o pang-aabuso) upang magmukha itong sinadya sa halip na sira. Nababawi ang suspensyon kapag nagbayad, nag-ayos, o umapela. Mas mahigpit ang quarantine at iba ang takbo nito: nababawi lamang ito pagkatapos ng paglilinis at pagsusuri, hindi kailanman awtomatiko.
Sa Zinn® Managed WordPress, oo — binibigyan ng CloudLinux alt-PHP ang bawat site ng sarili nitong tagapili ng bersyon ng PHP, sarili nitong mga extension gaya ng imagick, gd at redis, at sarili nitong mga pinatigas na setting, na nakapaloob lahat sa mga limitasyon ng LVE ng site na iyon. Sadyang nagpapatakbo ang Footprint-Free Hosting ng mas istandardisado at naka-lockdown na configuration sa bawat site, dahil ang pagkakaiba-iba ng configuration ay isang footprint din mismo.
Oo. Ang CloudLinux LVE at CageFS ang density-optimised na default sa parehong linya ng produkto. Para sa mga workload na nangangailangan ng mas matibay na hangganan, iniaalok ang ganap na container-per-site isolation bilang isang provisioning-driver variant — ang parehong engine at control plane na may ibang placement, ipinagpapalit ang overhead para sa mas malakas na paghihiwalay.
Oo. Nagsisimula ang Footprint-Free na hosting sa isang walang-kard na 14-araw na trial na sumasaklaw sa hanggang limang site — walang mga detalye ng pagbabayad, walang obligasyon. Mag-deploy ng ilang site, magpadala ng load sa mga ito, at tingnan kung paano gumagana ang mga cage bago kayo magpasya.
Magsimula ng 14-araw na pagsubok na walang kinakailangang kard sa Footprint-Free Hosting — hanggang sa limang site, walang detalye ng pagbabayad, walang obligasyon. Kasama ang paghihiwalay sa antas ng kernel, ang maagap na WAF, at pag-scan sa malware mula sa unang pag-deploy.
Magsimula nang libre