Mga FAQ ng Glasswall Halo

1. Ipinapadala ang file sa REST API.
2. Iniimbak ang file sa isang persistent volume sa loob ng cluster.
3. Isang mensahe ang ipinapadala sa Engine service upang iproseso ang file.
4. Tinatanggap ng Engine service ang mensahe upang iproseso ang isang file.
5. Binabasa ang file na iyon mula sa persistent volume at pagkatapos ay pinoprotektahan ng Glasswall Engine.
6. Pagkatapos ay iniimbak sa persistent volume ang protektadong file at analysis report.
7. Isang mensahe ang ipinapadala sa report extractor upang mabuo ang Engine report.
8. Pagkatapos ay ipinapadala pabalik sa API ang isang mensahe mula sa Engine service.
9. Tinatanggap ng API ang mensahe mula sa Engine at binabasa mula sa persistent volume ang protektadong file, report, o pareho, at bumubuo ng tamang tugon para sa client.
10. Pagkatapos ay ipinapadala ang isang mensahe sa report extractor mula sa API.
11. Tinatanggap ng report extractor ang mensaheng ito at bumubuo ng report mula sa analysis file at sa API.
12. Pagkatapos ay nabubuo ang metric data.
13. Sa huli, ang orihinal na file, protektadong file, at analysis report ay tinatanggal mula sa persistent volume.

Sinusuportahan ng Glasswall Halo ang malawak na hanay ng mga uri ng file kabilang ang mga PDF, Office documents (Word, Excel, PowerPoint), mga larawan, at iba pa. Tinitiyak nito na ligtas ang lahat ng naprosesong file at napapanatili ang kanilang orihinal na functionality.

Ang mga orihinal na file, protektadong file, at analysis report ay pansamantalang iniimbak sa isang persistent volume habang pinoproseso. Ang persistent volume ay sinusuportahan ng naaangkop na storage provider para sa deployment platform:

• Azure - Azure File Share
• AWS - Amazon Elastic File System (EFS)
• GCP - Google Cloud Filestore
• Oracle - OCI File Storage Service
• On-premise (RKE2/OVA) - lokal na disk

Ang mga ulat ng transaksyon, detalye ng file at mga buod ng pagproseso na ipinapakita sa Portal ay nakaimbak sa MongoDB.

Maaaring i-deploy ang Glasswall Halo sa isang Kubernetes environment, gamit ang Helm charts para sa madaling setup at configuration. Ang detalyadong mga tagubilin sa deployment ay ibinibigay sa dokumentasyon. Maaari ka ring mag-deploy sa pamamagitan ng isang OVA.

Isang error report ang ibinabalik sa user.

Ang mga orihinal na file, mga protektadong file at mga ulat ng pagsusuri ay inaalis mula sa persistent volume ayon sa policy sa pagpapanatili ng file. Nag-iiba ang asal ng pagpapanatili ayon sa paraan ng pagsusumite.

Sinusuportahan ng Glasswall Halo ang hanggang 5 antas ng mga nested archive.

Ang mga sumusunod na uri ng archive ay sinusuportahan sa Glasswall Halo: Zip, Tar, Zip, 7Zip, Rar.

• Payagan – 0
• Linisin – 1
• Huwag Payagan – 2

Sa loob ng tugon ng error, nagbabalik ang Glasswall Halo ng isang "code" na nagpapahiwatig ng isang partikular na sitwasyon.

Nagsisimula ang mga error code sa HTTP response code at may kasamang numero upang ipahiwatig ang partikular na error.
Para sa higit pang impormasyon, pakitingnan ang aming API documentation.

Oo, ang kasalukuyang configuration ay may kasamang contingency para sa mga workload na mas mahirap kaysa sa karaniwang file. Bagama't maaaring posible na taasan ang replicas count at makakita ng pinahusay na performance, ang maaaring maging resulta ay mas maraming error kung maubos ng sabayang load ang available na memory.

Posible ito at dahil dito ay maaaring baguhin ang replicas count bawat node nang hindi kinakailangang makaranas ng kakulangan sa compute resources.

Gayunpaman, ang pagtalaga ng mas maraming workload sa iisang node ay nagpapalaki sa blast radius sakaling pumalya ang isang node. Ang pagdaragdag ng node count ay maaaring makamit ang parehong layunin nang may mas mababang panganib.

Ang proseso ng CDR ay lumilikha ng isang intermediate representation ng orihinal na file, na maaaring mas malaki nang husto kaysa sa orihinal na file. Tinitiyak ng mga reserve value na maaaring maproseso ang maraming malalaking file.

Nagbibigay ang Glasswall sa mga customer ng karapatang magproseso ng ilang bilang ng mga file o dami ng data bawat araw.

Sa kasalukuyan, hindi nagpapataw ang Glasswall ng teknikal na limitasyon sa labis na paggamit, ngunit ang labis na paggamit ay ipinagbabawal ayon sa kontrata.

Isang layer para sa pamamahala ng lisensya ang ipakikilala sa Glasswall Halo, na magpapatupad ng mga limitasyon batay sa entitlement.

Sa kasalukuyan, walang mahigpit na limitasyon sa mga Engine call maliban sa mga ipinahihiwatig ng batayang configuration ng Helm Chart.

Maaaring i-throttle ng mga susunod na bersyon ang throughput upang umayon sa lisensyadong kapasidad kada oras at kada araw.

1 GB.

Ang ilang file ay maaaring mangailangan ng mas malaking memory upang mag-CDR dahil sa kanilang istruktura o mga kinakailangan sa representasyon ng modelo.

Ang Glasswall ay ang nangungunang provider sa mundo ng solusyong CDR at gumagamit ng piling mga third-party na component.

Tinitiyak ng mahigpit na static analysis, SCA, at IaC scanning na ang mga component na ito ay hindi nagpapasok ng mga kahinaan.
Transparent ang Glasswall tungkol sa mga dependency at nagpapatupad ito ng mahihigpit na pamantayan sa seguridad.

Gumagawa ang Glasswall ng mga SBOM para sa mga serbisyong bumubuo sa Halo deployment. Maaaring ibigay ang mga ito kapag hiniling.

Oo, tama iyon.

Ang Glasswall Halo ay idinisenyo upang tumakbo sa isang ligtas na kapaligiran — walang datos na ipinapadala pabalik sa Glasswall.

Maaaring humiling ang Glasswall ng mga summary log upang beripikahin ang pagsunod sa lisensya, ngunit walang anumang data ng customer ang kailanman lumalabas sa environment nang walang tahasang aksyon ng administrator.

Karamihan sa mga serbisyo ay lilipat sa isang hardened Alpine base image alinsunod sa mga gabay ng CIS.
Nagbibigay ang Alpine ng minimal, security-hardened na distribusyon ng Linux na may nabawasang attack surface.

Kapag overloaded ang Halo, maaaring maipon ang request queue at magbalik ng mga 429 error.
Sa kalaunan ay awtomatikong uubusin ng system ang backlog.

Kung masyadong matagal ito — at okay lang sa iyo na mawala ang mga naka-queue na mensahe — maaari mong i-purge ang queue:

kubectl exec -ncdrplatform -it RabbitMQ-server-0 -c RabbitMQ -- RabbitMQctl purge_queue engine-request-queue

Nagbibigay ang mga monitoring tool na naka-integrate sa Kubernetes ng mga insight sa performance, paggamit ng resource, at kalusugan. Ang maintenance at mga update ay pinangangasiwaan sa pamamagitan ng Kubernetes upang mapanatili ang seguridad at katatagan.

Gumagamit ang Glasswall Halo ng encryption, mga secure na communication protocol, mahihigpit na access control, at ang mismong proseso ng CDR, upang matiyak na walang mapaminsalang content ang makakalusot.

Nagbibigay ang Glasswall ng dokumentasyon, mga support service, at mga training resource para sa pagpapatupad at pamamahala ng solution.
Kasama sa support ang mga online resource, customer support, at mga community forum.

Nakadepende ang latency sa laki, uri, at pagiging kumplikado ng file.
Ang Glasswall Halo ay in-optimize upang mabilis na magproseso ng mga file para mabawasan ang delay.

Pinapayagan ng Kubernetes ang Glasswall Halo na awtomatikong mag-scale batay sa load.
Gamit ang KEDA, dinamikong ina-adjust ng Halo ang mga instance ng serbisyo ng CDR batay sa trapiko ng file.

Matuto pa tungkol sa Keda