Udgivet: 16. juni 2025 af PerfGrid

Pulse Uge 25

Den seneste måneds tid har vi foretaget en række ændringer af vores tjenester, og dem gennemgår vi i dette indlæg.

Generelle rettelser og forbedringer af Grid Hosting

Vi har implementeret mindre rettelser og forbedringer på vores Grid Hosting-platform. Nogle af dem forbedrer brugeroplevelsen, mens andre løser generelle fejl eller mindre problemer.

Rettelse af Valkey-statistikker

En af de mindre rettelser involverede visning af den seneste måling i Valkey-statistikkerne eller i visse tilfælde beregning af det korrekte gennemsnit over den 12-timers periode, vi viser målinger for. Dette var især tydeligt, når man først begyndte at bruge Valkey-funktionen.

Rettelse af Cron Jobs

Vi tilbyder composer og wp-cli (wp) i Grid Hosting, når du bruger SSH. Disse redskaber er dog gemt i /usr/local/bin, hvilket betød, at de ikke var direkte tilgængelige uden den fulde sti, når man brugte cron-jobs. Vi har siden løst dette ved at sikre, at PATH-variablen er indstillet korrekt for cron-jobs, og har skubbet denne ændring til alle cron-jobs, der er afhængige af noget, der ligger i /usr/local/bin.

Fix af System FTP-konti under oprettelse

Vi havde en fejl i systemet, som resulterede i, at System FTP-konti ikke blev oprettet korrekt, når de blev oprettet via vores API. Det betød, at standardbrugeren til panelet ikke havde FTP-adgang. Dette er nu blevet løst. Vi arbejder også på at aktivere FTP-adgang for disse systemkonti for alle eksisterende konti, der i øjeblikket ikke har det aktiveret.

Ny Funktion: Email tilladelses-/bloklister

Vi modtog en efterspørgsel fra en kunde om at implementere tilladelses-/bloklister for e-mailkonti i Grid Hosting-løsninger.

Når eemails går gennem vores Rspamd-spamfilter, får de en score. Afhængigt af denne score kan der foretages flere handlinger, f.eks. at acceptere e-mailen, markere den som spam og sende den til spammappen, greyliste eller direkte afvise emails.

Selvom vi generelt har få falske positiver, er der tilfælde, hvor man absolut vil sikre, at emails enten altid accepteres eller altid blokeres. Så vi har implementeret dette i panelet.

Tilladelses-/blokeringslister pr. modtager er faktisk ikke noget, som Rspamd tilbyder ud af boksen, så vi var nødt til at finde på en løsning, der fungerer godt for mange email-konti og samtidig er fleksibel nok.

Vores implementering involverede skræddersyet Lua-kode i Rspamd, hvor vi registrerer modtageren(ne). Derefter forespørger vi vores API for at hente tilladelses-/blokliste information og gemmer dem i en midlertidig cache på hver af vores indgående filterservere.

I Rspamd kan vi så træffe disse beslutninger ved at kontrollere afsenderen (både MIME og SMTP) og foretage en handling baseret på brugerens præferencer.

Interfacet giver dig mulighed for at tillade eller blokere individuelle afsendere, som f.eks. user@example.com, eller hele domæner, som f.eks. example.com.

Når vi modtager en email på spamfilterserverne, tildeler vi en prioritet. Hvis to regler matcher (f.eks. bloker example.com men tillad allow@example.com), så tager allow@example.com prioritet over example.com-reglen, fordi den er mere specifik.

Ny Funktion: Valkey data persistence

Vi har implementeret en mindre funktion i vores Valkey Manager: Du kan nu beslutte, om du vil gemme data i et interval eller ej.

Generelt ser vi, at de fleste bruger Valkey som en caching-mekanisme til WordPress, så det giver normalt ikke meget mening at gemme cachen på disken, da det betragtes som midlertidige data, og det ikke gør nogen skade at miste dem. Derfor gemmer vi heller ikke data som standard. Men hvis du bruger Valkey til at gemme data, der skal bevares, kan du nu styre dette direkte fra panelet.

Denne funktion blev også implementeret for at opnå en lille forbedring af ydeevnen ved ikke at bevare data som standard.

Midlertidige domæner er blevet forbedret

Vores tidligere implementering af midlertidige domæner var baseret på at omskrive data undervejs. Selvom dette gjorde det nemt at bruge, forårsagede det også interessante problemer i kombination med WordPress.

Hvis du f.eks. gemmer visse indstillinger i WordPress, vil vi omskrive oplysningerne i databasen, så de indeholder det midlertidige domæne, hvilket kan medføre mærkelige bivirkninger for hjemmesider, der bruger disse midlertidige domæner.

Derfor har vi besluttet at ændre den måde, systemet fungerer på. Når du aktiverer et midlertidigt domæne, tilføjer vi i stedet dette domæne som en separat "virtuel host" på webserveren, der peger på den samme mappe som det domæne, det er oprettet til.

Det giver også mulighed for meget bedre håndtering i WordPress.

Vi vil udvide denne funktion i de kommende uger ved at tilføje en funktion til vores 1-klik WordPress-installer, der kan opdatere data i databasen mellem det midlertidige domæne og det rigtige domæne, hvilket gør det nemt at teste under flytninger. Vi vil fortælle mere om dette, når det bliver tilgængeligt.

Derudover har vi nu tilføjet muligheden for at deaktivere midlertidige domæner, og vi har udvidet funktionen til underdomæner, hvilket ikke var muligt før.

Bonding af netværksinterfaces på alle servere

Da vi oprindeligt flyttede datacentre tilbage i december, gik vi over til en opsætning, hvor alle vores servere er forbundet til to TOR (Top-of-Rack) switche, hvilket giver ekstra redundans på det fysiske netværksniveau.

Mens de fysiske kabler blev tilsluttet under flytningen, krævede det også en software-/konfigurationsændring på alle servere. Vi gennemførte denne konfigurationsændring i løbet af weekenden (fredag → søndag), så nu er alle servere forbundet med to gange 10 gigabit -forbindelser, hvilket giver i alt 20 gigabits forbindelse pr. server. Denne ændring påvirkede serverne NLCP01 til og med NLCP08 samt NLSH04. NLSH05 og NLSH06 havde allerede bonding på plads fra deres oprindelige konfiguration.

Under vores første serverkonfiguration i fredags stødte vi på et problem, der forårsagede ca. 18 minutters nedetid på NLCP01 på grund af en firewall-indstillingen, der ikke var synlig i vores testmiljø. Da problemet blev fundet, blev ændringerne implementeret på tværs af vores servere før migreringen, hvilket betyder, at de resterende servere blev konverteret til den redundante opsætning med en nedetid på 20-60 sekunder.

Denne ændring giver os også mulighed for at opdatere vores switche uafhængigt af hinanden uden at påvirke serverens tilgængelighed, når vi udfører softwareopgraderinger.