Bekijk Volledige Versie : Is DPS echt een DPS?
Hallo,
Ik heb sinds een jaar een DPS, althans daar ga ik vanuit. Omdat ik bezig ben met Magento en zelf niet voldoende kennis heb heb ik een expert ingehuurd die af en toe met mij meekijkt en zaken op de DPS zonodig aanpast. Ook ben ik niet echt tevreden over de performance van de server. Hij vertelde mij (tot mijn grote verbazing) dat ik geen DPS heb maar een VPS.
De expert is een Engelssprekend persoon dus daarom even zijn opmerkingen in het Engels.
Hieronder zijn opmerkingen:
Xeon E5620 Quadcore 2.33 GHz, 8 GB
OpenVZ VPS willl show this information unchanged from HN, so even experienced Linux user can believe he has a dedicated server with these resources:
# free
Mem: 8154928 ...
# grep '^model name' /proc/cpuinfo
model name : Intel(R) Xeon(R) CPU L5410 @ 2.33GHz
model name : Intel(R) Xeon(R) CPU L5410 @ 2.33GHz
model name : Intel(R) Xeon(R) CPU L5410 @ 2.33GHz
model name : Intel(R) Xeon(R) CPU L5410 @ 2.33GHz
But these are physical resources distributed between all virtual environments. So if there are 50 other VEs on this HN, there resources are shared between them. Only 160G RAM are guaranteed for your VE now.
OK, let's suppose your VE is single on this HN. So you can request shell access to OpenVZ hardware node (HN) to view or control any VE on this HN.
> 2x 146 GB SAS Raid 1 [12418 + 12428 + 12464 + 90102]
This resource can not be checked inside VE. Shell access to HN is required. Only virtual file system (simfs) is visible in VE:
# df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/simfs simfs 123G 71G 53G 58% /
So ssh access to hardware node ("physical server") is needed to audit HDD resource
Hij is een Plesk Support Engineer en is overtuigd dat ik niet krijg waarvoor ik betaald heb.
Heeft iemand wat verdere tips voor mij?
Groetjes,
Koo
Ben ik de enige die niet weet waar DPS op staat. Google zegt alleen Damage per second, dat zal dit niet zijn gok ik ;-)
Dedicated Private server.
Ik vermoed dat de TS een dedicated server heeft afgenomen en een VPS heeft gekregen. VPSen worden soms ook al wel eens DPS genoemd.. Best verwarrend maar ik vrees uit de uitleg die de TS geeft dat het een VPS betreft..
Dedicated Private server.
Ik vermoed dat de TS een dedicated server heeft afgenomen en een VPS heeft gekregen. VPSen worden soms ook al wel eens DPS genoemd.. Best verwarrend maar ik vrees uit de uitleg die de TS geeft dat het een VPS betreft..Wat nog wel eens gebeurd is dat er een server draait met daarop één VM. Dat maakt de boel herstellen dan vaak een stuk makkelijker.
Of dat hier het geval is is zo niet te zien.
dennis0162
23/04/13, 14:47
Meestal is /dev/simfs een OpenVZ/virtuozzo VPS.
Je zou het voor de zekerheid nog even kunnen controleren door te kijken of /proc/vz/veinfo bestaat.
Er is niks over te zeggen of er nog meerdere VPS'en op de server staan.
Inderdaad niet te zien en zoals Wido zegt dat kan ook een reden zijn naar licenties voor bijvoorbeeld Plesk en Backup: die zijn een pak goedkoper in VPS model dan op een dedicated hardware.
Misschien gewoon is navragen bij je leverancier ?
Bij de leverancier navragen ga ik zeker doen, maar wilde eerst wat meer info.
Ik heb gekozen voor een DPS omdat ik dan zelf volledig verantwoordelijk ben voor performance. Er draaien ongeveer 30 sites op deze DPS en ik merk dat de performance niet echt goed is.
Het bestand /proc/vz/veinfo bestaat, wat zou ik hier aan af kunnen lezen?
Is er een manier om voordat ik de leverancier raadpleeg met zekerheid te kunnen zeggen dat het hier een DPS betreft?
Ik betaal voor deze DPS meer dan € 100,- per maand als het een VPS is dan kan dit veel goekoper met deze specs denk ik?
Bedankt voor de antwoorden tot zo ver,
Koo
dennis0162
23/04/13, 15:32
Dan is het 100% zeker een OpenVZ of Virtuozzo VPS.
Ok, maar is er een manier om uit te zoeken of er meer sites gebruikmaken van "mijn" hardware?
dennis0162
23/04/13, 15:56
Nee daar is niks over te zeggen.
Als je VPS traag is dan zullen er hoogst waarschijnlijk ook andere VPS'en op dezelfde server staan.
Of er zijn limieten opgelegd aan de VPS.
Volgens mij heeft OpenVZ alleen routed interfaces en geen bridges. Dan is je een na laatste hop de OpenVZ server.
Wat je dan kan doen is je eigen IP-adres ophogen als je nu 192.168.1.10 hebt eens kijken of 192.168.1.11 ook dezelfde hop heeft.
Je kan het natuurlijk ook gewoon aan je host vragen:)
Ik zou inderdaad bellen. Persoonlijk vind ik dat wanneer je een DPS besteld je deze normaliter ook gewoon moet krijgen en niet met een virtualisatie laag ertussen aangezien je toch een "klein" stukje prestatie verliest.. Nu kan het zijn dat je de enige bent op de node maar die kans lijkt me ook vrij gering vanwege het feit dat de server slecht performed en de betreffende hoster op dat moment zelf de fysieke node moet onderhouden als jij hier geen gegevens van hebt.
Dat het een openVZ container betreft is eigenlijk zeker! Dus ik zou hier zeker op doorzoeken en "per direct" de login gegevens van de fysieke node opvragen. Dus geef ze ook niet de mogelijkheid je VPS nog even snel te verhuizen naar een andere node.
Ik heb dit antwoord terugekren op mijn simpele vraag of mijn server een DPS is:
Your server is a DPS - which means you own 100% of the server resources.
But: It is installed with OpenVZ to
a) protect the server from kernel-hacks, as most of them don't work
b) protect your network packages from being sniffed / observed from other servers in our network, without the overhead of VLAN separation
c) allow exactly what I'm going to do now: Take your entire server and move it to different hardware
If you like, you can name a DPS to be a VPS with 100% of the resources of a server, so a single VPS per hardware node.
Ik heb dit antwoord terugekren op mijn simpele vraag of mijn server een DPS is:
Your server is a DPS - which means you own 100% of the server resources.
But: It is installed with OpenVZ to
a) protect the server from kernel-hacks, as most of them don't work
b) protect your network packages from being sniffed / observed from other servers in our network, without the overhead of VLAN separation
c) allow exactly what I'm going to do now: Take your entire server and move it to different hardware
If you like, you can name a DPS to be a VPS with 100% of the resources of a server, so a single VPS per hardware node.
Wat bedoelt hij met C# dat hij het gaat kopieren naar andere hardware? Daarnaast alsnog toegang tot de node vragen. Want niet vergeten dat een openv node ook gewoon een linux os is waar je risico op kernel-hacks loopt. Ook is een openVZ container gewoon een blokje dat gebruik maakt van de kernel van de node.
Voor mijn gevoel word je voor de gek gehouden.
Er wordt verhuisd naar andere hardware omdat er problemen zijn met DNS Lookups.
mgielissen
23/04/13, 20:07
Het kan zijn dat de provider openvz kiest ivm beheer. (firewall op de hwnode via FORWARD rules, rsync, vzctl enter ... zonder wachtwoord van de klant te hoeven weten, etc)
Patrick_st
23/04/13, 21:08
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.
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.....
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.
Patrick_st
23/04/13, 22:22
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?
systemdeveloper
23/04/13, 23:37
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.
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).
systemdeveloper
24/04/13, 00:51
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.
systemdeveloper
24/04/13, 10:26
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).
systemdeveloper
24/04/13, 11:47
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.
De controle login kan ook via een ander systeem van waaruit een sessie bestaat met screen en dat jezelf mee kijkt terwijl de klant controles uitvoert. Dan kun je controleren wat de klant doet. Zodra iemand een unmanaged dedicated afneemt lijkt het mij niet meer dan redelijk dat ook te leveren, als iemand een VPS afneemt dan zal dat geleverd moeten worden. In dit geval lijkt het te gaan om een tussen variant en de vraag is hoe duidelijk dat was voor de klant bij het afnemen. De term DPS had ik in ieder geval nog niet eerder gezien (gezien de uitvoering is het naar mijn idee enkel een VPS die toevallig een hele host gebruikt).
Yourwebhoster
24/04/13, 13:10
Ik had hem al een keer eerder zien voorbij komen en het kan inderdaad een hoop voordelen geven bij het beheer van een server.
TS: weet je zeker dat het de server is die traag is? Kan het niet zijn dat één van de websites brakke scripts of veel bezoekers heeft? 30 websites geeft eigenlijk niks aan. Facebook is ook één website maar heeft ondertussen wel een aantal datacenters met servers staan....
Dit is het laatste antwoord dat ik van mijn hoster ontvangen heb, ik moet eerlijk zeggen dat ik mij hierin wel kan vinden. Ben verder zeer tevreden, maar dacht door ook HN Access te krijgen de server meer te kunnen laten finetunen.
You ordered the product DPS - you received the product DPS. If you need the features you're talking of, server housing might be the better solution for you, but please don't order Product A and ask for features not included in that product and price range.
A shared root access to the hardware node would mean endless fights if something is not working, about who did that and who did not. It would mean to open SSH access down to server level to the internet - so a user changes his password to a weak one and the node is open for attacks. It would mean to change the entire network setup for this server to isolate it in a VLAN, it would mean that moving the DPS to new hardware - as we did it right now - would not be possible anymore without the risk of loosing all changes done outside of the container.
So the simple answer is NO. No access to the hardware node for DPS clients. We follow this policy years with success and will not change it.
If you choose for server housing on the other side, you get all this included: Be your own master on the server, install and change VPSes as you like - but you are also responsible for hardware issues and security then...
Als ik alle reacties zo lees van de hoster, ik ben het helemaal met ze eens. Kan het niet simpeler verwoorden :)