> -----Original Message----- > From: Andreas Kostyrka [mailto:andreas@;mtg.co.at] > Sent: Thursday, October 31, 2002 12:18 AM > To: [EMAIL PROTECTED] > Subject: RE: [vserver] Quotas > > Am Mit, 2002-10-30 um 22.52 schrieb Mefford, Aaron: > > I realize that I am new to the list and do not have much history, but I > am > > considering the possibility of using vserver on a fairly large project > and > > as such would like to at least take a moment to offer my opinion on a > couple > > of items. > > > > First, I almost walked away from using the vserver option until after > > joining the list I saw that the quota issue was being actively > addressed. > > Of the todo's left, quota was the biggest gap for my application. It > would > > be excellent to see the others addressed but without quota it would not > be > > an option. > It surely should be. Consider using LVM and sticking each vserver on > it's own logical volume. This way you can statically allocate space to > vservers and resize their needs online.
I am not familiar with LVM but will quickly become familiar. As long as it does not require a users space to be dedicated it will be a good answer it seems. The problem with a filebased filesystem is the commitment of unused resources. > > > > As to the specific post, I am not sure that the hard line of not > overbooking > > is a good idea. While for many applications it would be a correct > solution > > there are some where it will not. Every ISP over allocates their > available > > resources. People do not care to pay for dedicated resources. > > Additionally, with most services now being offered via resellers, it > seems > > unreasonable to not allow the reseller the same option. For instance, > if I > > sell virtual private servers, and joe buys a VPS with the intention of > > selling individual web sites run within the VPS, I may or may not want > to > > allow Joe to oversubscribe his disk s pace, possibly even on a per VPS > basis. > Thats what "soft" quotas are fore. Depending upon your guidelines when > someone oversteps the softquota, either the root@main or root@vserver > should decide if an upgrade of discstorage is needed and initiate it. > > Basically if you get 500MB/1000MB hard, you can overbook in the same > ratio your own users, ... > Soft quotas might suffice, but not really what I am after. Say Joe is a web developer who has bought a virtual server from me with 500 Mb of space. As the service provider I want a hard quota that will not allow joe to exceed 500 Mb, and would typically set a soft quota at 80-90% so that joe gets upgrade notices prior to running out of disk. Joe has a successful web development business and has 100 clients whom he has developed sites for and offers them hosting as well. Knowing these customers will only use 1-10 Meg of actual disk as he designs there sites, yet wanting the customer to feel comfortable that they are getting there moneys worth (every other provider is oversubscribing as well and the apparent cost of 100M is 1/10 its actual value) he gives each site 100M of quota. In doing this he knows that if one of his clients logs in and fills there quota he will still have disk left, and have the opportunity to upgrade to compensate after the fact. I monitor my actual disk usage and by another shelf of disk whenever I reach 75% usage. I have enough users that even if 10% of them decided to fill disk in a short period of time, space would still be available. > > > > I realize that implementing a solution that would support a hybrid > approach > > raises the complexity, but I wanted to state that there is value and > need > > for such an approach. > Well, the quota approach do have some problems (IMHO). Consider the > vunified system files. Do they count against the "main" root quota, or > against the "user" root quota? How is the Security Context a file > belongs to stored on disc? I think the majority of alternate products count unified files against system root and configuration and other per VPS files against user root. > > Andreas
