PDA

Bekijk Volledige Versie : Service bij een managed dedicated server



Derek-Jan
07/11/09, 18:54
Voor mijn webshops heb ik speciaal een dedicated server genomen. En aangezien ik van het beheer van servers geen verstand heb, heb ik een managed server genomen.

Nu heb ik de laatste tijd het idee dat het niet helemaal vlotjes loopt bij het management van mijn server. Oa een downtime van meer dan 12 uur en op dit moment een probleem met een ssl-certificaat.

Daarom vraag ik mij nu eens hardop af of het verwachtingsnivo van de service wellicht te hoog ligt? Verwacht ik teveel van mijn hoster?

Misschien kunnen jullie mij even terug op aarde brengen.

Het volgende gebeurt :

Op zaterdag avond circa 18u gaat de boel offline. Dit word binnen enkele minuten gemeld door een bezoeker van één van de sites. Ik meld dit op mijn beurt per sms en aansluitend per ticket bij mijn hoster. Zondagmorgen circa 11 uur draait alles weer. Reden downtime : 'Er is geen toegang via SSH omdat er een fout in de SSH-configuratie is gemaakt. Hierdoor start SSH niet op'

Zegt mij verder niets......

Volgende probleem speelt zich nu af :

Op 23-09 vraag ik een ssl-certificaat aan + installatie voor een nieuwe shop (domein is aangemaakt op server). Er word hierover nog gemaild en is betaalt en ik ga er vanuit dat dit in orde is.

De shop word woensdag/donderdag geinstalleerd en snacht's verander ik de nameservers. Vrijdagmorgen blijkt er een probleem met het ssl-certificaat te zijn (bezoekers krijgen melding certificaat ongeldig). Om circa 11 uur maak ik hierover een ticket aan.

Helaas geen respons en deze ochtend maak ik wederom een ticket aan, tevens mail ik op een voor mij bekend adres. Deze middag krijg ik respons dat er naar gekeken zal worden.

Allemaal leuk en aardig maar ondertussen heeft de programmeur niets meer kunnen doen en ik dus ook niet. De bezoekers krijgen nu een scherm met een foutmelding mbt certificaat - die komen dus niet terug.

Al met al ben ik nu dus behoorlijk pissig. Dat er ergens iets fout gaat heb ik begrip voor. Maar dat het niet op een behoorlijke termijn word opgelost kan er bij mij niet in.

Ben ik terecht pissig? Moet ik dit accepteren?

Heb alle contracten en av's inmiddels gelezen maar kom nergens iets tegen dat er een maximale termijn genoemd word (dus bv oplossing binnen 24u ofzo).

Onder kantoor uren vind ik een antwoord binnen een uur sowieso wel normaal voor een bedrijf wat 24/24 bereikbaar is (volgens eigen schrijven).

Het geeft mij in iedergeval weer stof tot denken bij de volgende dedi.

pierce
07/11/09, 18:59
Daarom vraag ik mij nu eens hardop af of het verwachtingsnivo van de service wellicht te hoog ligt? Verwacht ik teveel van mijn hoster?


De vraag is dan, wat voor service level ben je overeengekomen met je hoster?

Derek-Jan
07/11/09, 19:16
De vraag is dan, wat voor service level ben je overeengekomen met je hoster?

Daar ben ik dus nog niet helemaal achter. Ook een beetje doel van mijn vraag hier om er achter te komen wat dan minimaal het nivo is wat ik mag verwachten.

Ik ervaar het als normaal dat ik tijdens kantoortijd gewoon geholpen word, tenminste minimaal een reactie op een storing krijg.

Er zijn mij ook nooit opties aangeboden mbt SLA's, en eerlijk gezegd ben ik er pas achter dat dit blijkbaar een gemeengoed is in de hostingwereld.

Dit is trouwens helemaal de reden dat ik voor een managed dedicated server heb gekozen, om er vanuit te gaan dat alles gewoon opgelost word. Niemand heeft mij gezegd dat ik dan ook nog eens na moet denken over de termijn waarbinnen alles opgelost word.......

XBL
07/11/09, 19:38
Je kan er vanuit gaan bij een managed server dat alle problemen opgelost worden door je hoster, binnen wat er onder managed verstaan wordt. Het is daarnaast heel normaal om ook af te spreken hoe snel er gereageerd wordt cq er begonnen wordt aan het oplossen: binnen 4 uur kost veel, binnen 8 uur tijdens kantooruren kost een stuk minder.

Dit laatste is niet afgesproken (en ik betwijfel of de grenzen van wat managed is wel afgesproken zijn...), dus is het voor ons een beetje gissen wat normaal is. Als je relatief veel betaald, dan kan je ook relatief veel service verwachten. Binnen kantoortijden een snelle reactie is inderdaad ook normaal, maar zonder een eenduidig contract is dat allemaal lastig af te dwingen.

Ik zou met je hoster om de tafel gaan zitten en kijken wat zij verstaan onder managed. Tot waar ze je support geven en hoe lang het duurt voordat ze voor je aan de slag gaan. Zonder die afspraken kan je wel kijken naar iets wat 'normaal' is, maar zoals aangegeven worden er in deze business bijna zonder uitzondering harde afspraken gemaakt in de vorm van SLA's.

Derek-Jan
07/11/09, 20:00
Ik zou met je hoster om de tafel gaan zitten en kijken wat zij verstaan onder managed. Tot waar ze je support geven en hoe lang het duurt voordat ze voor je aan de slag gaan.

Zelfs hierover bestaat al een verschil van mening. Mijn programmeur heeft nu ssh toegang nodig om de installatie af te ronden en mijn hoster komt doodleuk af met de mededeling dat daarmee een deel van mijn SLA vervalt. (niets over kunnen vinden in de av overigens..)

XBL
07/11/09, 20:13
SSH toegang weigeren voor het root account is niet raar: met het root account wordt het beheer gedaan. Op het moment dat iemand anders dan de beheerder hier ook dingen mee gaat wijzigen (m.n. in belangrijke configuratie bestanden), dan loop het beheer natuurlijk helemaal in de soep. Maar SSH toegang moet gewoon kunnen met een normaal gebruikers account (met beperkte rechten).

Enfin, er is dus helemaal geen SLA afgesproken als ik het goed begrijp. In dat geval zou ik toch echt proberen de hoster iets op papier te laten zetten wat volgens hun de SLA omvat. Afhankelijk van wat jij had verwacht kan je dan kijken of je meer wilt of het voldoende vind. Dit is wel een beetje rare situatie, aangezien je dit soort dingen vooraf afspreekt.

Ik neem ook aan dat je bepaalde verwachten had bij 'managed' toen je deze server afnam? In hoeverre sluiten die verwachten aan op wat jouw hoster nu doet? En in hoeverre zijn die verwachten realistisch (in vergelijking met bijvoorbeeld andere partijen die hetzelfde doen)?

pierce
07/11/09, 20:13
Zelfs hierover bestaat al een verschil van mening. Mijn programmeur heeft nu ssh toegang nodig om de installatie af te ronden en mijn hoster komt doodleuk af met de mededeling dat daarmee een deel van mijn SLA vervalt. (niets over kunnen vinden in de av overigens..)

Je hoster heeft het nu over een SLA.
Welke SLA is dat dan, en wat is inbegrepen/afgesproken?

Boyke
07/11/09, 20:26
'De shop word woensdag/donderdag geinstalleerd en snacht's verander ik de nameservers. Vrijdagmorgen blijkt er een probleem met het ssl-certificaat te zijn (bezoekers krijgen melding certificaat ongeldig).'

Wie zegt dat jij het probleem niet hebt veroorzaakt met het wijzigen van de nameservers?

Derek-Jan
07/11/09, 20:43
'De shop word woensdag/donderdag geinstalleerd en snacht's verander ik de nameservers. Vrijdagmorgen blijkt er een probleem met het ssl-certificaat te zijn (bezoekers krijgen melding certificaat ongeldig).'

Wie zegt dat jij het probleem niet hebt veroorzaakt met het wijzigen van de nameservers?

Situatie :

shop A (oude layout - oud script) met domein X staat op shared server

shop B (nieuwe layout - nieuw script) met domein X word geinstalleerd op dedi server

voor domein X op dedi server word een ssl-certificaat aangevraagd

nameservers voor domein X worden snachts aangepast zodat vrijdag domein X verwijst naar shop B op dedi server.

Op vrijdag om circa 11 uur meld ik via ticket dat er iets fout is met ssl-certificaat. Aangezien de hoster dit certificaat geinstalleerd (ik ga er vanuit dat dat gebeurd is, daarvoor heb ik namelijk wel betaald) heeft ga ik er van uit dat hun ook kunnen zien of en wat er fout is?

Het minste wat ik verwacht is antwoord op die vraag. Ik mag er toch vanuit gaan dat dit geen dag hoeft te duren? Lijkt mij vanzelf sprekend en hoeft absoluut niet gedekt te worden door een SLA.

Derek-Jan
07/11/09, 21:27
Je hoster heeft het nu over een SLA.
Welke SLA is dat dan, en wat is inbegrepen/afgesproken?

Dit knip ik uit de offerte, in het contract staat verder niets vermeld.


Wat houdt Managed Dedicated Server nu precies in:
• Maandelijkse onderhoudsvenster; Software updates / Security updates.
• Dagelijkse externe backups via ons backup systeem.
• 24 uur per dag monitoring van de vitale diensten op uw systeem, middels SMS.
• Geen omkijken naar hardware, alles wordt door ons geassembleerd.
• Op verzoek wordt er software geïnstalleerd.

Heb nog wel redelijk wat mail correspondentie waarbij er toegezegd word dat ik er geen omkijken naar heb, dat ik bij problemen niets hoef te doen.

Maar er word niet over een tijdsbestek gesproken.

Dit knip ik uit de laatste mail :


Mocht er nu iets gebeuren en wij moeten optreden, valt dit natuurlijk buiten de SLA om. Een externe partij heeft namelijk nu toegang tot de server en wij weten niet wat zij installeren/doen.

Wel leuk gezegd, maar het bedrijf die mijn shop gebouwd heeft zegt ook dat hun de installatie via ssh moeten afronden anders werken er bepaalde zaken niet en heb ik geen recht op garantie bij storingen.

Dan zit je toch tussen 2 partijen in?

Mijn hoster leest trouwens mee hier op WHT, wat helemaal niet erg is. Iedereen kan hier van leren. Voornamelijk dat de klant een leek is die best voldoende gewezen mag worden op de mogelijkheden en onmogelijkheden.

Juist om 'gezeik' te voorkomen kies ik voor een managed dedi. Maar als er dan wat moet gebeuren en iedereen trekt z'n handen eraf.......

Mark17
07/11/09, 21:38
Kun je kijken of je hoster en je leverancier van je webshop contact met elkaar op kunnen nemen om het te regelen? Mogelijk kan de webshop leverancier bijvoorbeeld een copy/paste howto schrijven die vervolgens door je hoster uitgevoerd kan worden voor de installatie. Dan is mogelijk het probleem al op te lossen of SSH toegang onder "toezicht" verstrekken.

Hier wel eens gedaan dat iemand via een andere server in een screen sessie toegang kreeg tot SSH van een bepaalde server terwijl ik mee keek. Dan is bekend wat hij gedaan heeft en dit had verder ook geen effecten voor de SLA die de klant bij ons had afgesloten. Deze oplossing kost alleen wel vaak relatief veel tijd (en dat is saai naar een scherm kijken terwijl je enkel kijkt wat de ander doet). Mogelijk is dit een praktische oplossing voor het probleem.

XBL
08/11/09, 00:01
Volgens mij is het duidelijk wat ze qua ondersteuning doen: je OS aan de praat houden en op verzoek software installeren. Als ik het zo lees geven ze vervolgens verder geen ondersteuning op de software (of dat moet weer op verzoek).

Het probleem m.b.t. de SSH-configuratie valt onder het stuk wat zij onderhouden, iets dergelijks zou gewoon snel opgelost moeten worden en mag geen reden zijn tot zeer lange downtime. Maar onder wie het probleem met het SSL-certificaat valt is al wat vager.

Hoe dan ook, dat lijstje wat jij geven hebt is niet bepaald een SLA te noemen. Een SLA beschrijft nauwkeurig wie waar voor verantwoordelijk is en wat voor reactie tijden cq oplostijden (of wanneer begonnen wordt aan een oplossing) verwacht mogen worden. Dit kan heel simpel op 1 pagina, maar kan ook bestaan uit een dik pak papier. Dit vaak afhankelijk van hoeveel software er beheerd wordt.

Ik raad dus nogmaals aan hun definitie van managed te achterhalen en dit op papier af te spreken. Gezien ze blijkbaar jou ook willen beperken in het gebruik van bepaalde features (SSH toegang), zou ik ook afspreken wat jij allemaal mag doen met de server (persoonlijk zou ik dat formuleren als iets van 'alles mag behalve zaken waarbij een gerede kans bestaat dat het beheer niet meer volledig gedaan kan worden.' (Maar dan in een fatsoenlijke zin ;) ).

systemdeveloper
08/11/09, 00:38
Jammer dat je hoster hier vergeet te scoren bij zijn klant.

Niet werkende ssh, 17 (?) uur plat en dat moet dan nog door een bezoeker van je site doorgegeven worden (dus waarschijnlijk geen monitoring), SSL certificaat niet werkend opgeleverd?

Met of zonder sla, dit is toch gewoon prutserig?

t.bloo
08/11/09, 12:19
Een full managed dedicated server die zonder hele goede reden een dag lang offline is, lijkt me een miskoop. Een goede reden kan zijn dat het datacenter een erg groot probleem heeft of dat hele specifieke hardware of software defect is. Maar dat lijkt hier niet het geval.

SSH voor de manager zou nooit kapot mogen zijn. En dan nog is het binnen een kwartier te fixen via serial console, IPMI, iLO, DRAC, KVM over IP of wat dan ook. En als dat ontbreekt dan is het met een ritje naar het datacenter te fixen. Nou kan ik me voorstellen dat van zaterdag op zondag dat wel wat langer duurt natuurlijk, het blijft mensenwerk. Even vertellen wat er aan de hand is, is echter wel gebruikelijk.

Voor het installeren van sommige software is inderdaad vaak shell toegang nodig, maar zelden root toegang. Het lijkt me dat je daar wel uit moet komen, ten slotte heb je die server met een bepaald doel aangeschaft en het idee van een dedicated server is toch doorgaans dat je er iets specialers mee wilt doen. Anders kun je net zo goed voor een habbekrats shared hosting afnemen.

SSL certificaten kunnen lastig "repareren" zijn als de leverancier er bij betrokken moet worden. Dat kost al gauw een werkdag of twee, beetje afhankelijk van het type certificaat. Maar ook hier kan de hoster meteen melden, wat het probleem en de verwachting is.

Derek-Jan
08/11/09, 13:17
Voor het installeren van sommige software is inderdaad vaak shell toegang nodig, maar zelden root toegang. Het lijkt me dat je daar wel uit moet komen, ten slotte heb je die server met een bepaald doel aangeschaft en het idee van een dedicated server is toch doorgaans dat je er iets specialers mee wilt doen. Anders kun je net zo goed voor een habbekrats shared hosting afnemen.

Je slaat de spijker op z'n kop. Het was vooraf bekend met welk doel ik deze dedi afnam : een aantal webshops draaiend op magento. Daar heb ik zelfs softwarematig nog aanpassingen aan laten doen (die ook vooraf besproken waren).

Als je dan weet dat iemand er een shop op draait lijkt het mij wel bekend en ook wel logisch dat dat gewoon moet draaien.

Nu heb ik al sinds vrijdagmorgen een certificaat fout op één van mijn shops. Elke klant die nu die shop bezoekt komt niet meer terug, dat lijkt me duidelijk.

SSL certificaten kunnen lastig "repareren" zijn als de leverancier er bij betrokken moet worden. Dat kost al gauw een werkdag of twee, beetje afhankelijk van het type certificaat. Maar ook hier kan de hoster meteen melden, wat het probleem en de verwachting is.
Dan had men dat vrijdagmiddag al kunnen melden en had ik eventueel in overleg met de programmeur iets kunnen bedenken. Nu weet ik nog steeds niet wat het probleem is maar ik denk dat er helemaal geen certificaat is(kan ik dat zien in directadmin?)

De ellende is begonnen met de dedi. Vooraf was ik al geruime tijd klant met een resellerpakket en nooit problemen gehad, mijn vragen werden snel beantwoord en ook in het weekend. Sinds dat ik het contract voor de dedi getekend heb is de ellende begonnen.

Heb een aantal buitenlandse domeinen waarvan een aantal tld's hier ook niet op gezet kunnen worden omdat de ip's opeenvolgend zijn. Ik weet dat niet, maar ik mag toch van mijn hoster verwachten dat hij dat niet zo opzet, of minimaal mij erop wijst wat kan en niet kan?


Met of zonder sla, dit is toch gewoon prutserig?

Deze jongen is zwaar pissed off en als ik de reacties zo lees niet zonder reden. Dat was mijn initiele vraag : verwacht ik teveel van mijn hoster? Blijkbaar niet.

t.bloo
08/11/09, 13:24
Beetje afhankelijk van het type certificaat, kun je dat zien in DirectAdmin doordat er onder "SSL Certificates" in het onderste vak certificaat data actief is. Zie ook het plaatje.

Daarnaast kun je in je browser even kijken waar de site mee terug komt, daar zie je bijna alles aan.


Heb een aantal buitenlandse domeinen waarvan een aantal tld's hier ook niet op gezet kunnen worden omdat de ip's opeenvolgend zijn.
Ik snap niet wat je hiermee bedoelt? Lijkt me niet dat er eisen zijn aan de domeinnamen zelf, maar aan de DNS. Daar is soms een beperking op, maar je moet ook niet de DNS helemaal op je eigen server zetten natuurlijk.

systemdeveloper
08/11/09, 13:38
Laat je programmeur de boel even redirecten naar http ipv https. Heb je die vervelende melding niet meer om je bezoekers te laten schrikken en dan kan je hoster het morgen of zo fixen.

wonko
08/11/09, 13:55
een redirect gebeurt pas na de handshake, dus dan is het certificaat al doorgestuurd. SSL is een beveiligd communicatiekanaal!

Derek-Jan
08/11/09, 14:03
Oorspronkelijk geplaatst door Derek-Jan
Heb een aantal buitenlandse domeinen waarvan een aantal tld's hier ook niet op gezet kunnen worden omdat de ip's opeenvolgend zijn.
Ik snap niet wat je hiermee bedoelt? Lijkt me niet dat er eisen zijn aan de domeinnamen zelf, maar aan de DNS. Daar is soms een beperking op, maar je moet ook niet de DNS helemaal op je eigen server zetten natuurlijk.

Ik heb bv een aantal duitse domeinen. Als ik deze op m'n dedi zet en ik ga de nameservers aanpassen naar die van de dedi dan werkt dat niet. Jullie als hoster zullen daar best oplossingen voor hebben, maar het had ook simpel opgelost geweest met andere ip's, neem aan dat dat gewoon kan? Nogmaals ik ben een leek.

Zie hier : http://www.webhostingtalk.nl/domeinnamen-algemeen/153425-foutmelding-wijzigen-nameservers.html

Achteraf blijkt dus dat ik opeenvolgende ip's heb en dat dat dus problemen kan opleveren. Ik wist dus tot voor kort niet dat dat een probleem kan geven dus heb hier nooit bij stil gestaan.


Laat je programmeur de boel even redirecten naar http ipv https. Heb je die vervelende melding niet meer om je bezoekers te laten schrikken en dan kan je hoster het morgen of zo fixen.

Kan ik dit zelf ergens aanpassen, anders word het morgen...

Er staat nu overigens wel een certificaat op het domein zie ik in Directadmin.

vDong
09/11/09, 08:08
Ik heb bv een aantal duitse domeinen. Als ik deze op m'n dedi zet en ik ga de nameservers aanpassen naar die van de dedi dan werkt dat niet. Jullie als hoster zullen daar best oplossingen voor hebben, maar het had ook simpel opgelost geweest met andere ip's, neem aan dat dat gewoon kan? Nogmaals ik ben een leek.

Zie hier : http://www.webhostingtalk.nl/domeinnamen-algemeen/153425-foutmelding-wijzigen-nameservers.html


DeNIC doet dat expres om proberen af te dwingen dat je je nameserver spreid, dat is namelijk een goed idee, als je server lange tijd down is (meer dan je ttl) zullen je email en websites bij het terugkomen van de server nog minstens de ttl down kunnen zijn.

Ik zal je met alle plezier een aanbieding doen voor secondairy dns, echter denk ik dat de laatste posting (de secondairy van transip gebruiken) een better idee voor je is. Doe dit echter niet alleen voor je .de's, maar wees slim en doe dit voor al je domeinnamen.

Derek-Jan
09/11/09, 15:21
Iedereen bedankt voor z'n input. Ik ga eerst het één en ander voorleggen aan m'n hoster en kijken of het kan verbeteren.

Certificaat probleem is nog steeds niet opgelost overigens.

DUR0N
15/11/09, 21:08
een redirect gebeurt pas na de handshake, dus dan is het certificaat al doorgestuurd. SSL is een beveiligd communicatiekanaal!

Niemand draait zijn webshop uitsluitend op https://xxxxxxx?
http, dan redirect naar https, toch? Anders krijgt iemand waarbij https uitstaat of poorten heeft dichtstaan gewoon niets, ipv een pagina dat hun browser de vereiste authenticatie niet kan behandelen.