Dette indlæg er alene udtryk for skribentens egen holdning.

Golgafrincham Server model 2

13. oktober 2016 kl. 00:2822
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Jeg går og roder med en spritny server for en kunde og jeg har brug for at tilføje et emne på "The Agenda Rock", lige efter hvilken farve ild skal have.

Den originale IBM PC brugte ca en million instruktioner fra reset signalet meldte klar til koden i den første sektor på floppydisken blev startet.

Jeg har stadig en 386sx maskine der giver mig et 386BSD 0.1-newer prompt indenfor 10 sekunder af power-up.

Den her spritnye maskine har brug for en progress-bar for at fortælle hvor langt den er nået med at få stablet det der skal gøre det ud for BIOS'en sammen.

Artiklen fortsætter efter annoncen

Hvis man vil i kontakt med den indbyggede RAID diskcontroller, skal man vente nogle minutter på den tragedie, derefter trampe rundt i nogle menuer og finde det rigtige obskure punkt.

Herefter booter maskinen noget der ligner en Debian kerne og starter X11 & Mozilla hvorfra man kan konfigurere diskcontrolleren.

Det skal siges at leverandøren har gjort sig den umage at ingen af de fire "splash-screens" man tvangsudsættes for undervejs er ens.

Skulle man formaste sig til at skifte mode på diskcontrolleren tipper maskinen med hatten til Windows/95 og forlanger et reboot.

Samme sted adskellige minutter senere, kan man få lov til at fortælle den hvad den skal bruge sine diske til.

Og reboote igen.

Hvis jeg ikke vidste bedre, ville jeg postulere at denne storm-p konstruktion af utilpassede og samspilsramte stykker klytkode var sammenbragt med vilje, med det ene formål at lave god plads til mal-ware, bagdøre og overflødig 3.parts software.

Vel at mærke med en indbygget fall-back plan, der skal få folk til at bruge de meget nemmere aflyttelige "cloud" services frem for egne servere.

Men jeg ved bedre, det er ikke med vilje, det er bare woodoo programmering af værste skuffe og lag, på lag, på lag, på lag af dårlige ideer, implementeret til et 4-tal af døve programmører ledet af blinde marketingsfolk.

Grunden til at jeg ved det, er at direktøren for Golgafrincham forleden, helt uironisk, pev over at PC og server markedet ikke er hvad det har været.

... og understregede overfor investorene at der ikke var noget Firmaet kunne gøre ved det.

Hver gang jeg rebooter den server de har produceret har jeg et par minutter eller tre til at reflektere over hvor sandt det tydeligvis er.

phk

22 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
21
15. oktober 2016 kl. 10:54

Coreboot/libreboot - som er en erstatning for BIOS - giver væsentligt kortere boot tid. Hvis hurtige reboots er en prioritet kunne man købe fx ASUS KGPE-D16 som er et af de få moderne server bundkort som understøttes:https://www.coreboot.org/Supported_Motherboards

18
13. oktober 2016 kl. 22:50

Vores ZTE routere kan hot patches. Men det er dog ikke alt der leveres som hot patches. De store opgraderinger kræver fortsat reboot, ligesom at det kan være at delsystemer oplever en kortere afbrydelse. Jeg modtog for nyligt en patch hvor de gjorde opmærksom på at pakkeforwarding ville blive afbrudt i nogle få sekunder.

Jeg tror også mere på redundans og i den forbindelse har vi FRR (Fast ReRoute) hvor man på forhånd har alternative paths indlæst i hardware. Dermed kan man route udenom et nedbrud på optimalt 50 ms, hvilket er alt rigeligt til vores formål.

Vi peerer på NL-IX men vi vil ikke opleve samme slags nedbrud som i den historie Jn Madsen fortæller. Vi har valgt at have to peering porte, to routere og to forskellige lokationer. Hvis den ene router crasher, så har alle vores peers stadig en route til den anden router. Og internt har vi værktøjer som FRR og hierarkisk FIB til hurtig recovery.

Alt det er stadig ikke nogen undskyldning for at det skal tage 15 minutter for et reboot af linjekortet i routeren. Nogle gange er man bare i en situation hvor teorien er god nok, men man har glemt et eller andet og nu er nede alligevel indtil den s** dims er genstartet.

Sjovt nok så starter route engine (CPU kortet i routeren) på 5 minutter. Hvis man har et serielkabel til den, så kan man arbejde i konfigurationen med mere alt imens at man venter på at linjekortene også kommer online. Uden linjekort kan routeren naturligvis ikke udføre noget nyttigt arbejde i praksis.

17
13. oktober 2016 kl. 18:05

Og det er ikke noget nyt. AT&T's første computerstyrede telefoncentraler kunne og blev opgraderet under live traffik.</p>
<p>

Som gammel telemand, der nu er "netværksmand", trækker jeg på smilebåndet. I den gamle televerden var vi hysteriske omkring oppetid og kvalitet. Det var dyrt, kompliceret og flueknepperi i alle hjørner,- men det virkede fænomenalt. Vi testede typisk en STM16=2,5gb i 2-3 uger med fuld tryk på trafik generatoren. Ruskede i stel og kabler, - efter testperioden måtte der ikke være en eneste bitfejl. Udstyret kom simpelthen ikke i drift før årsagen var lokaliseret og rettet.

Nu sender man 3 ping,- "Det er ok". Efter 20 år har jeg stadig ikke vænnet mig til det :-)

Moralen var: Om 10 år ved ingen hvor lang tid du var om det,- men man kan se hvor dygtigt du var.

12
13. oktober 2016 kl. 12:29

Det er sådan cirka der man finder ud af at nogle trixy dele af konfigurationen, som blev lavet for 2-3 år siden, aldrig er skrevet til flash-storage ...

Jeps, - efter nogle hændelser af sådan en slags, så begynder der at komme nye emner op til møderne. Provisioneringsværktøjer, logging af bruger kommandoer og konstant backup med compare og klokkeslæt ...... og lignende :-)

Pyt med det,- at lave fejl der annonceres i landsdækkende presse er bare et tegn på, at man er ved at have et interessant job :-)

10
13. oktober 2016 kl. 11:59

I erkendelse af at det meste kode til interface af HW er klytkode, så tror jeg også at jeg kunne have fundet på at kræve en reboot...

Min erfaring siger at mange dimser og dingenoter som opfører sig underligt, kan betragtes som et HW-problem der er opstået i et eller andet 'hjørne', hvor softwaren ikke har ...lad os bare sige formået, at initiere til en kendt tilstand.

Min generelle opfattelse er at 'man' kun vælger at initiere nok til at dimsen virker i labtesten "Se, nu tænder vi og det virker hvergang".

Når der så kun laves warm-boot bliver obskure indstillinger , aktiveret via register Z, ikke fixet - simpelthen fordi dette register ikke bliver initieret.

Dette er nok ikke tilfældet hér, men man garderer sig til en vis grad mod at andres klytkode får det til at se ud som det er din klytkode der er skyld i at deres dims ikke virker.

K

9
13. oktober 2016 kl. 11:39

Grunden til mange køber IBM/Dell/HP er support aftalerne, hvis noget fejler er det rart at have replacement hardware on site inden for max en time.

Havde en HP server der rebootede spontant mindst én gang i døgnet (undrede mig over den hele tiden blev slave selvom jeg havde promoted den til master dagen før - nyt setup, så der var ikke etableret overvågning). Jeg skulle lige finde den rigtige webform... men så gik der ikke mere end en time før jeg havde en tekniker i røret der kunne sende mig en beta bios opgradering der løste problemet indtil officiel release blev tilgængelig.

7
13. oktober 2016 kl. 10:25

En af grundene til at raid-controllere er langsomme i opstart, er staggered start, for at alle harddiske ikke spinner op samtidigt, og dræber psu. Unødvendigt for de fleste. Nye serverboards har nemt 10-12 sata porte, sog software raid er hurtigere og mere pålidelig end det meste hw raid.

... men når det er sagt er HP, IBM, Dell forfærdeligt langsomme. Hvorfor ikke stemme med fødderne og vælge noget andet? Jeg har et taiwan brand server stående med Xeon og masser af DDR4 ecc ram i, og det fungerer aldeles glimrende. Alt er alligevel uhyre tæt på intel reference design, og IBM, DELL, HP er kun billigere i start indkøb fordi det er låst på dyre upgrades.

6
13. oktober 2016 kl. 10:14

Vi bruger en del Dell R920/930, de tager uden problemer op til 15min om at komme forbi POST, forstår heller ikke helt hvad det skal til for, jo den skal konfigurere hukommelsen (de har et par TB hver), men det burde vel trods alt ikke tage lang tid.

Altid noget man kan angive hvilken bios/enhed man vil boote fra/ind til ved næste genstart i idrac, ellers kan man hurtigt spilde en del tid hvis man glemmer at trykke de rigtige tastatur genveje under POST.

4
13. oktober 2016 kl. 09:25

Nu er IT jo godt på vej ind i bilerne og alle de kendte dårligedomme kommer åbenbart med. Men bilerne har jo allerede haft computer ombord i mange år - og alle de biler jeg kender til starter prompte når man drejer nøglen (selv diesel når det ikke er for koldt). Det kan da godt være at alle systemer er fuldt initialiserede. Men jeg kan da få øjeblikke efter jeg har drejet nøglen køre ud af indkørslen mens jeg skruer ned for radioen der netop er kommet til live.

Selv hvis batteriet har være taget af, er det ikke sådan at jeg skal vente minutter på at bruge bilen.

2
13. oktober 2016 kl. 07:50

Jeps. Minder mig om en stresset situation for en del år siden. Alt for mange jobs på skrivebordet, kø bag ens stol af jamrende teknikere der står med "uløselige" problemer. Jeg sidder og skal reloade et slot i en international peering-router placeret i London.

Pga stress/træthed/uopmærksomhed bytter jeg rundt på 2 ord i en lang syntax streng.

Jeg reloader ikke et slot,- men hele kassen. Min ssh promt fryser, og det gør jeg også :-) Al international peering i et geografisk område er lige klippet af.

Skod software,- hvis der er kompleks QoS på kortene, træder der (efter producentens udsagn (it's not a bug, it's a feature)) nogle watchdogs i gang, som gør at en reload som minimum tager omkring 4 timer. Gerne meget længere. Måske 6-8 timer, måske bliver kassen endnu mere mopset. Hvis sådan en kasse skal reloades, så skal alle QoS konfigurationer pilles af først, for at forhindre de watchdogs i at komme på banen.

Nå,- kassen kom i luften igen, inden den tekniker vi smed på et fly var kommet frem. Han kunne have fremskyndet processen ved at rive kort ud af maskinen. Jeg kunne "sole" mig i meddelelser annonceret i dagspressen vedrørende "midlertidige problemer med internettet" :-)

Skod software,- men de kasser eksisterer heller ikke mere. Nu om dage bruges netværks elementer der aldrig skal reloades, heller ikke ved sw-opgraderinger.

1
13. oktober 2016 kl. 01:02

I et tidligere job brugte vi meget servere fra IBM. Fine maskiner men det tager minimum 5 minutter at nå igennem BIOS inklusiv scanning efter SCSI enheder som det slet ikke er muligt fysisk at montere i maskinen.

Tanken må have været at det ikke er en vigtig parameter. Man kan sætte junior sysadmin til at installere operativsystem, så who cares? Det skal jeg fortælle dig: Det gør direktøren når du må fortælle ham at vi er nødt til at lave et reboot mere og at det tager i hvert fald 5-10 minutter bare fordi. Alt imens at forretningen er nede. Det hjælper i hvert fald ikke i en stresset situation.

I mit nuværende geschæft bruger vi almindelige bambus servere som kan boote på under et halvt minut. Nu er det routere og switche der er problemet. Linjekortene i vores hovedrouter kan være 15 minutter om at komme online efter en genstart. WTF?! Hvis der har været et router crash, så er det da med at komme online igen hurtigst muligt og ikke om 15 minutter, hvad f*** tænker de på?

Vores GPON access switche er omkring 5 minutter om at starte men det er på en tom opsætning. Jo flere kunder der er på switchen, jo længere tid før alle er online. Den er ude af i stand til at "starte" kunderne parallelt og i stedet sker det sekventielt. Da der kan være op til 512 kunder på en enkelt switch, så kan det tage en rum tid før den sidste kunde er online igen.

Hvorfor kan de ikke se, at selvom det er rigtigt at vi ikke render rundt og rebooter i tide og utide, men når det sker, så er det uacceptabelt med ekstra nedetid bare fordi en eller anden klaphat ikke fatter at køre nogle processer parallelt?