Onderwerp: Is DPS echt een DPS?

100 euro per maand is 6000 in 5 jaar (de tijd dat de server mee gaat)
Een stukje marge voor de hoster er af, stroomkosten er af, data kosten er af. Volgens mij blijft er dan max 3000 euro voor de server zelf over.
Dat kan wel uit met de hardware specificaties die hier genoemd worden.

Ik vind het niet zo netjes dat ze niet van te voren melden dat je een VPS krijgt op je dedicated hardware maar er zijn genoeg redenen te verzinnen waarom dit eerder een voordeel dan een nadeel is.

De VPS kopiëren naar een andere server met als rede DNS problemen vind ik dan wel weer wat apart.

Het bleek dat de netwerkkaart kapot was en hierdoor zijn de DNS Lookup problemen ontstaan. Sites wereken nu weer goed.

Oorspronkelijk geplaatst door KooTjoo

Het bleek dat de netwerkkaart kapot was en hierdoor zijn de DNS Lookup problemen ontstaan. Sites wereken nu weer goed.

Ik probeer met erg veel moeite een scenario te bedenken waar dit kan gebeuren, maar het lukt me niet. Ik durf niet onmogelijk te zeggen, maar onwaarschijnlijk dat deze reden waar is durf ik wel.

Op mijn vraag naar login fysieke node krijg ik het volgende antwoord:

we COULD do so - but that would give you the power to do exactly what we want to block - access to our internal network, to the kernel, to package sniffing, etc. pp.
Your bank would also not let you into their central safe.....

Oorspronkelijk geplaatst door KooTjoo

Op mijn vraag naar login fysieke node krijg ik het volgende antwoord:

we COULD do so - but that would give you the power to do exactly what we want to block - access to our internal network, to the kernel, to package sniffing, etc. pp.
Your bank would also not let you into their central safe.....

Des te meer ik hun in twijfel ga trekken. Ten 1e een server met die specificaties en die hardeschijven moet met een paar sites gewoon snel zijn. Daarnaast wat vDong zeg is een DNS lookup probleem onmogelijk te herleiden naar een netwerk adapter als al het andere internet verkeer nog goed werkt.

Daarnaast is het onzin dat je niet op de fysieke node zou mogen. Elke dedicated server provider geeft je gewoon toegang tot je dedicated server zonder deze problemen. Met andere huren je HUURT een dedicated server dan lijkt het me niet meer dan normaal dat je ook ECHT een dedicated server krijgt tenzij anders besproken.

Als het gaat om een managed dedicated server, dan valt er iets voor te zeggen. In elk ander geval: als ik een kluis bij een bank afneem, dan verwacht ik zelfstandig toegang tot deze kluis te hebben.

Voor wat betreft de netwerkkaart is dit de reactie:

I know it for sure. Since the server is offline, we were able to run some tests and found problems in the UDP package handling - and that is the protocol used by DNS lookups from most DNS servers. As it seems, it works for a certain amount of packages, then it fails for several minutes, works again for a certain amount of packages, etc. pp.

En.......inderdaad problemen zijn weg.

Zo ver ik kan lezen heeft de hoster het prima opgelost... of lees ik het verkeerd?

Oorspronkelijk geplaatst door vDong

Ik probeer met erg veel moeite een scenario te bedenken waar dit kan gebeuren, maar het lukt me niet. Ik durf niet onmogelijk te zeggen, maar onwaarschijnlijk dat deze reden waar is durf ik wel.

Ik kon me dat een tijd geleden ook niet voorstellen, totdat ik opeens haperingen op nfs (over utp) zag. Behoorlijk onverklaarbaar aangezien tcp verkeer zonder problemen werkte, maar de nic vervangen en het probleem was inderdaad weg.

Oorspronkelijk geplaatst door systemdeveloper

Ik kon me dat een tijd geleden ook niet voorstellen, totdat ik opeens haperingen op nfs (over utp) zag. Behoorlijk onverklaarbaar aangezien tcp verkeer zonder problemen werkte, maar de nic vervangen en het probleem was inderdaad weg.

Vervangen door hetzelfde type nic of een ander type? Als het een ander type was dan kan het ook nog een "driver" zijn die het probleem veroorzaakte (die nu niet meer gebruikt wordt).

Oorspronkelijk geplaatst door Mark17

Vervangen door hetzelfde type nic of een ander type? Als het een ander type was dan kan het ook nog een "driver" zijn die het probleem veroorzaakte (die nu niet meer gebruikt wordt).

Het was een broadcom of rt onboard dingetje van een normale server. Vervangen door een dual intel kaartje en geen problemen meer mee gehad.

@Pantsy, de hoster heeft het inderdaad prima opgelost en overall ben ik ook zeer tevreden, ik wil alleen het optimale uit de server halen en heb daarvoor een extern iemand ingeschakeld. Naar aanleiding van het niet toestaan van hardware access komt hij met de volgende opmerkingen, ik ben benieuwd wat jullie daarvan vinden?

However I continue to insist that shell access to HN could provide very convenient features. For example:
* NIC errors are not visible in VPS on virtual network interfaces (but are visible in HN), so we had no chances to notice NIC problem.
* Full hardware and OS status control is possible only in HN, not in VPS (for example hardware performance can't be evaluated by direct tests in VPS).
* It's fast and reliable to reboot VPS by simple "vzctl restart ..." command in HN
* It would be easy to create additional VEs for your needs to isolate services (like Mysql) or even clients to balance resources and protect others from "bad" domains.
* Clustering in OpenVZ is interesting solution, because virtual NICs in OpenVZ are extra fast (other virtualization systems can't reach OpenVZ performance)
* It would be possible to create VPS for backups available by extra fast virtual network
* More confidence to your provider (curtained windows are suspicious).

> we COULD do so - but that would give you the power to do exactly what we want to block - access to our internal network, to the kernel, to package sniffing, etc. pp.
Arguments are technically correct, but:
* You are not interested to put any harm on provider's network: package sniffing etc. This is absurd argument: you are not interested in breaking your business base.
* Your clients are isolated in VPS. They can't access internal network, kernel modules etc. HN is not intended to run services excluding SSH, so there's no additional features for hackers.

> Your bank would also not let you into their central safe.....
It looks for me as false statement. In this case usual dedicated server could be also such "central safe". Moreover, HN runs only SSH service, no WWW, FTP etc to attract hackers or bad clients.

Er is wel iets voor te zeggen natuurlijk. Wij hebben ook vpssen die gegroeid zijn tot vrijwel de maximale resources van een bepaalde node. In dat geval heb je een 'DPS'.
Voor de hoster heb je dan wel redelijk wat voordelen zoals de mogelijkheid tot onderhoud van de hardware zonder dat je de klant moet lastigvallen (move het vps naar een andere server met voldoende resources en je bent vrij om de hardware te vervangen zonder dat de klant uren down is).
Ook snapshots/backups gaan dan redelijk ongehinderd.

Maar je zit ergens wel met een stukje vertrouwen dat je moet hebben dat je hoster de boel niet overselled en dat ie fatsoenlijk de hardware monitorred.

Het feit dat je geen interesse hebt om schade aan de hoster zijn netwerk toe te brengen geloof ik best, maar jij (of iemand die je HN root logins steelt) kan het natuurlijk wel. In het kader van 'vertrouwen is goed, controle is beter' lijkt het me voor de hand liggend dat de hoster je niet de logins van de HN geeft. Je neemt tenslotte een 'dps' af en niet een 'ds'

Enkel door de gekozen virtualisatie techniek (gekozen door de hoster, niet door de klant als ik het goed begrijp) zit je mogelijk wel met beperkingen. Denk bv aan het bijwerken van de kernel of het wijzigen van kernel instellingen.

De zin 'vertrouwen is goed, controle is beter' kan ook omgekeerd uitgelegd worden. De klant wil in dit geval de hoster controleren, dat is echter niet mogelijk door het ontbreken van bepaalde logins bij de klant. Een tijdelijke login zou hiervoor mogelijk een optie zijn (controle uitgevoerd -> login weg).

Oorspronkelijk geplaatst door Mark17

Enkel door de gekozen virtualisatie techniek (gekozen door de hoster, niet door de klant als ik het goed begrijp) zit je mogelijk wel met beperkingen. Denk bv aan het bijwerken van de kernel of het wijzigen van kernel instellingen.

De zin 'vertrouwen is goed, controle is beter' kan ook omgekeerd uitgelegd worden. De klant wil in dit geval de hoster controleren, dat is echter niet mogelijk door het ontbreken van bepaalde logins bij de klant. Een tijdelijke login zou hiervoor mogelijk een optie zijn (controle uitgevoerd -> login weg).

Kan, echter ikzelf zou een klant nooit een login geven op een essentieeel onderdeel van een netwerk. Nog niet eens als dat account alleen maar 'ls' mocht uitvoeren.
Ik zou hem desnoods wel info geven zoals screenshots van whatever hij vraagt, maar een controle login.... never.