Golgafrincham Server model 2

Af 22

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.

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

Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Baldur Norddahl

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?

  • 22
  • 0
#2 Jn Madsen

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.

  • 12
  • 0
#4 Ole Kaas

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
  • 1
#6 Michael Hansen

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 så 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.

  • 2
  • 0
#7 Lars Andersen

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.

  • 1
  • 0
#8 Michael Hansen

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.

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.

  • 5
  • 0
#9 Ole Kaas

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.

  • 1
  • 0
#10 Kenn Nielsen

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

  • 1
  • 0
#11 Jn Madsen

Nu er jeg ikke opdateret på området, så jeg spørger måske lidt dumt, hvilket mærke/producent eller model?

Jeg vil være så fair at undlade at nævne fabrikat og model. Det var omkring 2008, og på det tidspunkt var mange af producenterne ikke helt oppe i gear endnu. Det er blevet bedre.

Lad mig nøjes med at sige "Den største kasse fra den største producent, men ikke sidste nye model" :)

  • 1
  • 0
#12 Jn Madsen

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 :-)

  • 7
  • 0
#17 Jn Madsen

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

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.

  • 10
  • 0
#18 Baldur Norddahl

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.

  • 3
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen