Wat is een VPS? [basis uitleg]

Het is zeer interessant hoe deze procedure te werk gaat. Een VPS verbinding is zeer voordeliger ten opzichte van standaard Shared Hosting. Maar toch vraag ik me af hoe het zit met het beheren van een domein aan de hand van een controle panel waarbij een licentie achter hangt.

Als we PLESK 30-domains als voorbeeld nemen met 10 VPS verbindingen. Moeten we dan per VPS verbinding een 30-domains licentie kopen of kan PLESK zien dat VPS wordt gebruikt? Je kan natuurlijk op een VPS meer domeinen aanmaken. Als PLESK 1 VPS als 1 domein ziet is dat natuurlijk voordeliger maar dat mag volgens mij niet.

Ben benieuwd hoe dat precies zit

Ik denk niet dat je begrijpt wat een VPS precies inhoudt. Een VPS is geen verbinding (waarschijnlijk zit je dan te denken aan een VPN - dat is totaal wat anders).

Een VPS is een virtuele server. Plesk "ziet" de VPS niet, maar Plesk draait op de VPS zelf. In dit opzicht kun je een VPS zien als een volledige zelfstandige server - en ook Plesk werkt in dat opzicht precies hetzelfde. Je kan op 1 VPS bij wijze van spreken 10000 domeinen hosten met een Plesk unlimited licentie.

Stel je hebt 3 VPS's draaien op een server. Je kan dan bijvoorbeeld op VPS-1 cPanel draaien, op VPS-2 Plesk 30, en op VPS-3 Plesk unlimited.

even iets uit stof halen misschien dat mijn vraag hier op verkeerde plaats woord gesteld mijn excuses bij voorbaat stel ik richt een server in als vps en deel hem door 4e dus 4 vps op een server

moet ik dan voor elke vps een aparte licentie aanschaffen van een controle pannel laten we zeggen DA moet ik nu 4x DA nemen of kan ik zeggen DA maak op vps 1 die domeinen en op vps die domeinen zodat ik het met 1 licentie af kan (ik heb nog geen ervaring met vps en DA)

Bij mijn weten kan dat niet.

In iedere VPS (Dus ieder OS) heb je een directadmin licentie nodig. Je kunt wel gebruik maken van VPS licenses; die kosten maar 5 dollar per maand.

bedankt voor de toelichting

wits nooit wat het betekende :P maar nu wel mooie uitleg ;)

Een grotere bottleneck waar niet zo snel een oplossing voor is, is disk i/o intensieve applicaties, als databases. Disk i/o is een groter probleem dan cpu. Een cpu bottleneck is op te vangen door een zwaardere processor of meerdere cpu's of een tweede machine in de farm. Door de virtualisatielaag zit er een vertraging in de disk i/o. Dit verschil is merkbaar als je een fysieke database server naast een virtuele database server zet. Daarom worden bij ons de productie database servers op fysieke servers gezet en ontwikkel/test en acceptatie servers op virtuele servers.

Citaat:

---

Oorspronkelijk geplaatst door Jandar

Een grotere bottleneck waar niet zo snel een oplossing voor is, is disk i/o intensieve applicaties, als databases. Disk i/o is een groter probleem dan cpu. Een cpu bottleneck is op te vangen door een zwaardere processor of meerdere cpu's of een tweede machine in de farm. Door de virtualisatielaag zit er een vertraging in de disk i/o. Dit verschil is merkbaar als je een fysieke database server naast een virtuele database server zet. Daarom worden bij ons de productie database servers op fysieke servers gezet en ontwikkel/test en acceptatie servers op virtuele servers.

---

Dit hoeft niet. Je kan een virtuele machine, afhankelijk van de software welke je gebruikt om te virtualiseren, ook raw-disk toegang geven. Dan zit daar geen laagje meer tussen.

Citaat:

---

Oorspronkelijk geplaatst door Jandar

Een grotere bottleneck waar niet zo snel een oplossing voor is, is disk i/o intensieve applicaties, als databases. Disk i/o is een groter probleem dan cpu. Een cpu bottleneck is op te vangen door een zwaardere processor of meerdere cpu's of een tweede machine in de farm. Door de virtualisatielaag zit er een vertraging in de disk i/o. Dit verschil is merkbaar als je een fysieke database server naast een virtuele database server zet. Daarom worden bij ons de productie database servers op fysieke servers gezet en ontwikkel/test en acceptatie servers op virtuele servers.

---

Inderdaad, zoals bakkerl al aangaf is dat niet waar. Bij bijvoorbeeld Virtuozzo wordt er direct van de disk gelezen, daar zit geen virtualisatielaag tussen.

De reden dat I/O nog wel eens een probleem is, is het feit dat sommige hosts denken dat je 20 VPS's ook gewoon van normale SATA schijven kan laten draaien. Als je gewoon 10.000RPM (of meer) schijven gebruikt in RAID 10, dan heb je dat probleem totaal niet.

Bij XEN kun je bijvoorbeeld met LVM groepen werken in plaats van de diskimages. Dit scheelt aanzienlijk met de snelheid én is ook nog eens stukken makkelijker met het maken van backups en snapshots. Wido heeft ooit eens een goede howto gepost op WHT.

Vmware heeft een performance test gedaan waarbij ze Raw i/o met hun eigen VMFS vergelijken. het resultaat van dat onderzoek kun je hier lezen

http://www.virtualization.info/2008/...-raw-disk.html

Uit dit onderzoek blijkt dat bij random I/O vmfs en RDM (raw disk) vrijwel identiek presteert. bij sequentiele toegang met kleine i/o blokken presteert RDm net iets beter.

Alleen het punt van discussie hier is ga je een dedicated schijf aan maken (schijf per vps) of maak je een shared disk aan waar je meerdere vps'en op zet.

De omgeving waar ik in zit heeft 34 hosts waar ca 900 vps'en op draaien. als je meerdere vps'en op 1 shared disk gaat zetten wordt disk i/o wel degelijk een punt om naar te kijken aangezien meerdere vps'en van dezelfde disk queue gebruik maken.

Overigens was ik in mijn verhaal ervan uitgegaan dat we alleen SAN based of scsi based schijven gebruiken, Sata is leuk maar vooral in een hobby sfeer....

Citaat:

---

Oorspronkelijk geplaatst door Jandar

Overigens was ik in mijn verhaal ervan uitgegaan dat we alleen SAN based of scsi based schijven gebruiken, Sata is leuk maar vooral in een hobby sfeer....

---

Tussen Sata-, SCSI- en SAS-disken zit niet meer zoveel verschil tegenwoorig. Het zit hem meer in de apparatuur welke de disken aanstuurt. Tegen de caching van een SAN omgeving kan een standaard RAID controller niet op.

Klopt, maar het feit blijft dat Sata gepositioneerd is als thuis markt of near line storage, scsi heeft het einde van zijn road map bereikt en ik denk dat er geen grotere scsi schijven meer gaan komen dan wat er nu aanwezig is, SAS is de opvolger van SCSI, SAS staat ook voor Serial Attached Scsi. Van Sata wordt verwacht dat het de 600Mbps gaat bereiken terwijl voor SAS een roadmap tot 1200Mbps heeft en daarnaast heeft SAS een grotere MTBF dan SATA. ik weet wat je wil zeggen maar de kans dat een SATA schijf eerder stuk gaat dan een SCSI/SAS blijft groter.

Op de betere Raid controllers zit een behoorlijke cache, natuurlijk is deze niet zo groot als bij een SAN maar bij een SAN moet je meer aan het aantal spindles (schijven) denken dan aan de caching, raid controller= 1 computer, SAN = x aantal computers, dus voor 1 computer is een interne Raid controller de beste oplossing, bij meerdere computers kun je na gaan denken over een SAN afhankelijk van de aan te sluiten storage en de te verwachten groei.

Overigens op de SAS Raid controllers kun je ook SATA schijven aansluiten, dan kun je met SATA schijven toch gebruik maken van de advanced caching van een Raid controller.

Citaat:

---

Oorspronkelijk geplaatst door Jandar

ik weet wat je wil zeggen maar de kans dat een SATA schijf eerder stuk gaat dan een SCSI/SAS blijft groter.

---

Dat hoeft in deze discussie niet echt een argument te zijn, het gaat om de snelheid, niet de levensduur. Een schijf in een raid array kan natuurlijk heel gemakkelijk vervangen worden (zeker met een hotspare).

Citaat:

---

Oorspronkelijk geplaatst door Jandar

Overigens op de SAS Raid controllers kun je ook SATA schijven aansluiten, dan kun je met SATA schijven toch gebruik maken van de advanced caching van een Raid controller.

---

Klopt, maar daarvoor heb je niet per se een SAS raid controller nodig. De duurdere raid controllers van 3ware en Areca bijvoorbeeld hebben dit ook.

Laat er overigens geen misverstand bestaan; ik ben zelf groot voorstander van SAS. Het is hoe dan ook beter dan SATA, maar ook voor SATA zijn genoeg argumenten te bedenken om dit te gebruiken (is natuurlijk helemaal afhankelijk van de rest van de configuratie).

Ik wil voorstellen om deze discussie verder voort te zetten in een nieuw topic - laten we het on-topic houden (ik weet het, ik maak me daar zelf ook schuldig aan :))