sisblog

11111

Op dit moment zijn er exact 11111 domeinnamen actief in onze shared hosting omgeving. Leuk getalletje, maar er kunnen er nog wel wat bij

Stroomstoring LCL Diegem: bang afwachten

Gisterenmiddag rond 16 uur kreeg ik plots alerts dat we meerdere andere netwerken die in hetzelfde datacentrum zitten als wij - we nemen rechtstreeks af bij LCL - niet meer bereikbaar waren.

Onder andere Combell, Priorweb, Cogent, Evonet, Tiscali, Rackboost en Openminds lijken last gehad te hebben van de storing. Gezien ze niet allen tegelijk offline zijn gegaan vreesden we even zelf problemen te kunnen hebben (We nemen immers ook rechtstreeks af bij LCL). Stroomuitval is immers een kleine ramp: schijven kunnen kapot gaan en het kan gebeuren dat je een heel systeem op consistentie moet controleren wat vaak enkele uren duurt.

Er ging ook één van onze uplinks offline, gelukkig zijn hebben we meerdere transit uplinks waardoor we hierdoor niet geaffecteerd
waren. Een klein probleem ivgl met wat andere partijen moesten ondergaan.

De storing heeft voor sommige partijen meer dan 4 uur geduurd . Voor de oorzaak is het nog wachten op een verklaring van LCL.

Dit allemaal ondanks maandelijkse blackout tests en tests van de generatoren.

De storing duurde wel erg lang, ik ben benieuw naar de oorzaak en wat LCL gaat doen om dit te vermijden. We hopen dat dit geen structureel probleem is en we met een gerust hart onze systemen in LCL kunnen houden.

In elk geval wens ik de getroffenen veel sterkte toe.

.vl nog niet voor morgen

De afgelopen weken krijgen - door de regerings- en staatshervormingsperikelen de vraag of het binnenkort mogelijk zal zijn .vl en .wl namen te registreren bij onze hosting diensten en wat er dan zal gebeuren met de .be extensie.

Het zal er echter nog niet zo snel komen. De splitsing zit er nog niet direct aan te komen en een uitdovingsscenario voor het .be domein is ook niet voor binnenkort.

Pierre vroeg Peter Vergote, medewerker op het ‘legal department’ bij dns.be om meer informatie en dit was zijn antwoord:

“.be is een zogenaamde ccTLD, een landgebonden domeinnaamzone. Deze worden gecreëerd op basis van de ISO-3166 lijst van de International Standardisation Organisation. Voor meer info over de ISO en ISO-3166 lijst zie: http://www.iso.org/iso/country_codes.

DNS BE is de technische beheerder van de .be domeinnaamzone en heeft als dusdanig geen impact op de geo-politieke ontwikkelingen binnen België. Indien .be zou komen te verdwijnen dan komt in feite ook het maatschappelijk doel van DNS BE te vervallen. Indien het land uiteenvalt in meerdere regionale entiteiten die elk op zich een staat vormen dan zullen hiervoor nieuwe codes in het leven geroepen moeten worden. Wie de beheerders van die nieuwe ccTLD’s zouden kunnen zijn, staat op dit ogenblik niet vast. Vast staat wel dat DNS BE zeker niet automatisch de opvolger kan zijn en het beheer van de eventuele nieuwe ccTLD’s op zich zou kunnen nemen. Het zal aan de respectievelijke regeringen van die nieuwe entiteiten zijn om te bepalen wie en onder welke voorwaarden het beheer van de betrokken domeinnaamzone op zich gaat nemen.

Het scenario van de uitdoving van .be en de creatie van nieuwe zones (.vl voor Vlaanderen, .wl voor Wallonië) is absoluut nog niet voor morgen. Ten eerste wordt een bestaande ccTLD code niet zomaar uitgefaseerd (er wordt al jaren geprobeerd om de code .su van de vroegere USSR buiten gebruik te stellen maar tot nader order worden nog steeds nieuwe registraties uitgevoerd binnen het .su domein). Ten tweede kan ICANN maar de creatie van bv. een .vl goedkeuren wanneer eerst de ISO 3166-lijst wordt bijgewerkt. Dit laatste zal sowieso ook wel een paar jaar in beslag nemen.

Ik denk dat u dus best de boodschap overmaakt aan uw klanten dat het einde van .be nog niet meteen aan de orde van de dag is.”

De petitie op http://www.puntvl.net/ om .vl te laten erkennen als ccTLD bij ICANN zal dus ook niet veel uithalen.

A Life Like Mine

Ooit, in mijn nog zorgeloze studententijd, hield ik mij met heel andere dingen bezig.
Samen met enkele vrienden hadden we een vrij egocentrisch ‘avant la lettre’ blog-projectje:

A LIFE LIKE MINE

We hadden het ideetje om elke dag foto’s te trekken van ons doen en laten en er een uitleg bij te plaatsen.
Mijn kot had toen immers een ongelimiteerde 10Mbit verbinding met VAST ip.
Er stonden al servertjes onder mijn bed voor enkele projectjes van Pierre. Hij was toen bezig met ‘Unified’ een soort ‘community’ CMS. (Sites die daar nog op zijn code draaien: levels4you.com en tricord.be.

Ik herinner me nog dat we toen om de eerste server installatie ‘te vieren’ een paar halve liters bier hebben gedronken… Toen wisten we niet dat we 4 jaar later een bedrijf zouden oprichten in dezelfde richting.

(Foto van de servertjes op mijn kot toen: hier en hier ). Vrij ghetto dus.

Hoe het allemaal begon…

Op een dag leende ik van Jan Van Cauwenberge een digitale camera.
En zo ontstond het idee om alles online te publiceren.

Wat ohp code geschreven en nog voor flicker bestond hadden we onze eigen fotoblog!

Alles kwam er op: foto’s van mijn eten, feestjes, reizen, lessen informatica in de S9, foto’s van cursuspagina’s tijdens den blok, en veel veel meer (alles quoi)… Naar het einde toe waren het wel bijna uitsluitend fotoreportages van feestjes.

Er zijn er meer dan 24.000 foto’s gepubliceerd…

Er was toen zelfs niet echt sprake van het begrip ‘blog’:

Een artikel in de De Gentenaar spreekt van ‘log’: http://www.gentenaar.be/Article/Detail.aspx?ArticleID=NBRA11062003_002

En het was nog vrij populair ook:

Photographs: 24123
Days: 784
Page Views: 4602371

4,6 miljoen pagevieuws … van de 12.000 sites die we nu hosten komen er maar een paar in de buurt…

Wat ook opvalt: Toen moest het nog in het Engels (en ja mijn Engels is wat brak) omdat internet toen minder gelokaliseerd was dan het nu het geval is. Ook de evolutie van de kwaliteit van de digitale camera’s is in die paar jaar ook enorm geevolueerd.

De door mij geschreven php code is ook niet erg fris meer, en er staat content op waar ik mij nu van distantieer.
Wie goed zoekt vindt ook foto’s op die tegen mij gebruikt kunnen worden.

Maar hey: Ik heb een periode in mijn leven die volledig gedocumenteerd is. Wie kan dat zeggen?
Het is ook grappig te zien hoe ik ben bijgekomen tijdens mijn studententijd en ik ben geevolueerd tot wie ik nu ben.

Begin 2002: http://www.alifelikemine.be/diary2.php?name=jan&day=03042002&i=7
Eind 2004: http://www.alifelikemine.be/diary2.php?name=jan&day=06122004

Ondertussen zit ik weer op mijn gewicht van 2002 maar het heeft wel een half jaar lijnen en sporten gekost.

Pierre is ook helemaal veranderd:

http://www.alifelikemine.be/stein/15092003/DSC02483.JPG

The End:

Op een dag vond de unief het nodig om het lijntje te limiteren en een VPN verbinding in te voeren.
Het was toen gedaan met de pret maar onder de vleugels van een bedrijfje waar ik toen voor werkte had ik een huurserver ter beschikking. Later is 1-eurohost.com ontstaan met als doel ook anderen gebruik te laten maken van de server(s).

Alifelikemine stierf een stille dood in 2004 toen mijn leven een wat andere wending nam: te druk als praeses van Home Vermeylen, nieuwe liefde in mijn leven en toen Stone Internet Services opgericht werd was er al helemaal geen tijd meer voor.

Wel raar om foto’s van toen terug te zien.

Ik heb zin om mijn shouders weer onder zo’n projectje te zetten.
Maar ja… tijdsgebrek.

Menselijk kapitaal

De afgelopen maanden ben ik niet meer in LCL geweest voor echte problemen waar manuele interventie vereist is. Dit bewijst dat de huidige setup goed draait (op 1 node na, die dringend moet gemigreerd worden naar een systeem met hardware raid want de io schiet wat te kort, maar die machine is al besteld). Yay!

Het moet nu lukken dat ik, net nu Pierre (alweer) op skivakantie is, ik de backup server per ongeluk halt…
Geen direct probleem ware het niet dat een klant net een backup nodig had.
Helemaal naar Brussel in de fucking hitte gewoon om op de powerknop te duwen… Frustrerend.

Balen, vooral omdat de support en sales vragen tijdens mijn afwezigheid zich verder opstapelden.

Het geautomatiseerde en met het webhosting controlepaneel geïntegreerd klanten-, administratie- en registratiesysteem heeft ons werk minder verlicht dan gedacht. We moeten nog altijd bij veel mensen hun handjes vasthouden. Men verwacht dat we door de klanten zelf geschreven scripts, of die van anderen debuggen. Erger nog zijn degenen die te lui zijn om bijvoorbeeld een mailbox in te stellen en ons een ‘welgemeende fuck you’ terug mailen nadat we hen uitgelegd hebben dat ze dat in enkele klikken zelf kunnen instellen. Het houdt ook nooit op.

Wat vond ik in mijn mailbox vandaag:

“Ik heb vorige week bij jullie ….be besteld, we zijn een week verder en jullie hebben nog altijd geen website voor mij gemaakt. Ik zal contact opnemen met Test Aankoop om dit aan te klagen.”
… Wij doen enkel hosting, we maken geen sites voor klanten…
“Ik heb een A record aangemaakt voor ‘domeinnaam.be’ en en www.domeinnaam.be verwijst niet naar het IP.”
… Klant had inderdaad een A record ingesteld maar enkel voor domeinnaam.be .
“Mijn site werkt niet meer, ik heb nogthans op disable gedrukt en bevestigd.”
… Klanten kunnen hun sites ‘disablen’ via een schakelaartje.
“Ik krijg al twee weken om de dag een mail dat mijn domeinnaam zal vervallen indien ik niet betaal. Vandaag werkt mijn site niet meer, waarom?.”
… Klant had uiteraard niet betaald
“Ik heb mijn ticket gesloten en jullie hebben niet meer op mijn vraag gereageerd.”
… duidelijk…

Urgh…

De volgende investering is in menselijk kapitaal…

Surf ook ’s nachts en red de planeet

Vandaag viel mij de vrij grote fluctatie op in het stroomverbruik van de servers die ten dienste staan van onze webhosting diensten. Het valt meteen op dat er ’s nachts ongeveel 10% minder verbruikt wordt. Logisch natuurlijk, de sites van onze - hoofdzakelijk Benelux klanten - worden enkel overdag druk bezocht:

Hetzelfde patroon zien we niet terug bij het verbruik door een deel van onze colocatieklanten (tweede grafiek). Vermoedelijk gewoon omdat hun servers meestal voor andere doeleinden gebruikt worden (applicaties, andere webdiensten) en ze minder last hebben van die dag/nacht fluctuatie. De dalen worden enkel veroorzaakt door het verwijderen van materiaal voor onderhoud.

Conclusie: de stroom die s’nachts nodig is om de continue beschikbaaarheid te garanderen wordt niet optimaal benut. De hoeveelheid opgevraagde data bedraagt tijdens de nachtelijke uren slechts 10 procent van wat het overdag is en toch verbruikt het geheel 90 procent van de stroom. Indien men meer ’s nachts zou surfen zou dat ’sluikstroomverbruik’ iets beter benut worden.

Voor een datacentrum is het handig dergelijke data te analyseren. De stroom, koeling en backup moet voorzien zijn op die pieken. De vraag rijst dan natuurlijk hoe men best factureert: op het gemiddelde verbruik, op het totale effectieve verbruik of op het piekverbruik. De kost van de voorzieningen kruipt uiteraard in de pieken waar het datacentrum rekening moet mee houden. Ik verwacht dat men de komende jaren dan ook gaat factureren op piekverbruik.

Rush

Damn wat een rush… plots een fijn idee voor een nieuwe dienstverlening. Zal vrij uniek zijn voor de Benelux. Financieel kunnen we het zeker inpassen zonder er onze broek aan te scheuren en als het losloopt kunnen we er nog een aardig centje aan overhouden.

Doelgroep is wel weer low budget maar het product is iets anders dan shared hosting. Rootservers voor het grote publiek :). Het zullen wel qua performatie geen ‘gebruikelijke’ dedicated servers zijn maar qua performatie zou het beter moeten presteren dan een uit de kluiten gewassen VPS.

Nu ja, ik wacht met spanning op het testsysteem.

Contracten

Zonet nog de laatste formaliteiten afgerond voor de verhuis naar LCL Diegem. Lang geleden dat ik nog zoveel geparafeerd heb.

Onze racks zullen van hetvolgende type zijn: Minkels VMC226010S, wel met 80% doorlaatbare deuren en cijfersloten. Er zou 21 cm speling zijn voor onze cable managers en natuurlijk de zero U apc (die eigenlijk in ons huidig rack gewoon niet past).

Daarnaast is de Interoute setup procedure in gang gezet, het interoute implementations team in Praag zal ons eind deze week contacteren met verdere formaliteiten.

Ik heb van de gelegenheid ook gebruik gemaakt om de aansluiting bij FreeBix aan te vragen. Hopelijk zullen we daar enkele interessante peering partners vinden.

Soit, ik kijk uit naar 1 september:

- Eigen Datacentrum ruimte in plaats van onze huidige gehuurde rackspace
- Steviger netwerkje:
- 100 Mbit Interoute
- 100 Mbit Realroute
- 100 Mbit Ams-ix en Bnix peering via proserve
- 100 Mbit FreeBix

En de volgende stap…

Het is zo ver: vanaf 1 september hebben we onze eigen serverruimte (5 aaneensluitende prints en 2 full racks voor direct gebruik) in het LCL datacentrum te diegem. Dit betekent dat we nu niet alleen bandbreedtegewijs (we rijn RIPE LIR en hebben ons eigen AS) onafhankelijk zijn van onze leveranciers maar ook wat betreft de fysieke serverruimte. Deze huren we momenteel bij Belgian Network Solutions.

Het is een moeilijke beslissing geweest omdat deze oplossing veel duurder is dan de huidige. Het is vooral op vlak van stroomkosten dat we nu een stuk meer gaan mogen betalen.

Daartegenover staat dat we alles in eigen handen gaan hebben, we competitief en flexibel colocation kunnen bieden en we ruimte hebben voor groei. Per 1 september wordt onze interoute uplink in LCL aangesloten en iets later verhuizen de andere links naar LCL. Normaal komt FreeBix er dan ook bij.

Deletes

Vandaag heb ik mij beziggehouden met het doorvoeren van de deletes van de gratis .be namen. Ik had beter de delete onmiddelijk meegegeven met de registratie maar ik stond er toen niet bij stil. Omdat we liever geen factuur voor de verlenging van 40.000 .be domeinnamen in de bus krijgen (€240.000) heb ik vandaag preventief via een script die de EPP server van dns.be aanspreekt alle namen een delete gegeven.

Ik heb dit vooraf voorgelegd aan de techs van dns.be of dit wel geen probleem zou opleveren als ik hun systeem plots 40.000 deletes doorvoer. Het zou geen probleem zijn.

Proces dan maar gestart en het gaat wel maar zo tergend traag… Het systeem kan blijkbaar per connectie niet meer dan één request per seconde verwerken. Dus het script zal dus 40.000 seconden moeten lopen, een goeie 11 uur dus… Zucht…