13 replies to this topic

[Bluesplinter]

Since I see you guys are now starting to migrate your shared servers to Cloud Linux, I guess you really believe in the technology. So, I have some questions...

1) Can an existing CentOS server with DirectAdmin be moved to Cloud Linux, and what impact would there be to existing sites/clients during the transition?

2) Does the account-level isolation mean SuPHP is no longer needed, and I can finally move to FastCGI?

3) Since each account gets a slice of isolated resources, does that mean low-traffic sites waste resources while heavier-traffic sites starve? From what Andrew wrote, I understand that you can adjust these settings per account... but unless each site always uses exactly the same resources, then that'd have to be constantly monitored and adjusted. Or am I misunderstanding this?

Thanks :)
Steve

[CH-Andrew]

Hello Steve,

Bluesplinter said:

Since I see you guys are now starting to migrate your shared servers to Cloud Linux, I guess you really believe in the technology. So, I have some questions...

Yes, it will be a very important piece of technology for us moving forward...

Quote

1) Can an existing CentOS server with DirectAdmin be moved to Cloud Linux, and what impact would there be to existing sites/clients during the transition?

An existing CentOS server can indeed be upgraded to CloudLinux OS fairly seamlessly (a few reboots is required). Currently however, Cloudlinux is not supported on DirectAdmin. We expect this to change in the near future

Quote

2) Does the account-level isolation mean SuPHP is no longer needed, and I can finally move to FastCGI?

Correct, you can likely move away from SuPHP if that is what you are currently using as it is somewhat redundant and not worth the inherent downsides any longer. You could run FastCGI right now, but, I take it you have chosen to go the SuPHP route for various reasons?

Quote

3) Since each account gets a slice of isolated resources, does that mean low-traffic sites waste resources while heavier-traffic sites starve? From what Andrew wrote, I understand that you can adjust these settings per account... but unless each site always uses exactly the same resources, then that'd have to be constantly monitored and adjusted. Or am I misunderstanding this?

Well, there are several ways to approach this. Typically what you would do (and what we are going to do on our shared servers in Phase1), is set global resource max limits that will affect all accounts sharing the sever. Lets say you set the limits to 30%-50% max resource utilization for all accounts as a global setting in a shared environment. What this would do is limit a single account (depending on how allocated you are and what your environments baseline utilization rate is) from bringing down an entire server if it came under attack, received a massive burst, etc.. as a single account, if the environment is not too overloaded, can use 30-50% of the server resources and it will not bring down service for other customers. This provides a buffer where the environment can be looked at, the cause of the spike can be analyzed and addressed. In this manner, there is no need to continually monitor and change allocation sizes for each and every account. Just find a "number" that works and allows customers to operate seamlessly on a day to day basis and also allows for significant spikes (good or bad) to occur without bringing a server down.

The method in which we will be selling this in shared hosting is a little different. We are going to integrate this into hsphere as a resource (same as disk space or bandwidth) and integrate directly with the cloudlinux core code. meaning when accounts are created (depending on what plan is purchased), that account will have a set amount of resources allocated to it (which is how we will be selling shared hosting packages in the not too distant future). Customers can then upgrade their plans to higher level plans, and more resources from within their control panel (just as they do today with space and bandwidth). This will be a pretty unique deployment. I honestly do not see this being the "normal" usage for customers with VPS servers, Cloud servers or Dedicated servers. I would "expect" CloudLinux to be used as a "buffer" for shared hosting environments, more so then granular resource allocations tied into plans and accounts. Though, I would not be surprised to see it evolve this way in a more wide spread manner then just with Cartika in the future. It simply makes too much sense - but, I think most will be slow adopters here and most will simply focus on utilizing this new OS to prevent a single account from taking down a server via the global resource allocation mentioned above and to prevent the spread of viruses, etc amongst shared hosting tenants..

Hopefully I have provided enough detail here, however, please do let us know if you have any additional questions...

[Bluesplinter]

Hey Andrew,

Thanks, that clears some things up re: max resources, etc. Please post when DA is available for Cloud Linux.

Quote

You could run FastCGI right now, but, I take it you have chosen to go the SuPHP route for various reasons?

That's the way your folks set it up, and I'm not familiar enough with what would change in a switch to FastCGI to make that call with confidence.

The primary thing that works perfectly now, that I would not want to lose, is how the user:group allows WordPress installs to have the access it needs to the file system without needing to give loose perms (or my having to manually change the group to httpd, as I used to have to request for HAL sites). With suPHP, a client can install WP, and the server already has proper perms to create upload directories, cache, etc.

I don't know if FastCGI will work this way. I do NOT want to have to manually change perms or group every time WP (or another PHP script) is installed... that's the only thing I disliked about HAL, and I'm sure your techs got sick of me posting that request! :)

Steve

[CH-Andrew]

Bluesplinter said:

That's the way your folks set it up, and I'm not familiar enough with what would change in a switch to FastCGI to make that call with confidence.

The primary thing that works perfectly now, that I would not want to lose, is how the user:group allows WordPress installs to have the access it needs to the file system without needing to give loose perms (or my having to manually change the group to httpd, as I used to have to request for HAL sites). With suPHP, a client can install WP, and the server already has proper perms to create upload directories, cache, etc.

I don't know if FastCGI will work this way. I do NOT want to have to manually change perms or group every time WP (or another PHP script) is installed... that's the only thing I disliked about HAL, and I'm sure your techs got sick of me posting that request! :)

Steve

Hello Steve,

fair enough...

yes, HAL was not running on fastcgi, so, you would have needed permissions changes in order to accommodate the functionality you desire along with good security.

Fastcgi resolves those issues, as does SuPHP. If our techs set you up with SuPHP when going over your specific requirements during the deploy process, I would certainly stick with what they configured for you, as I would be willing to wager its the best solution based on your specific requirements that were communicated. This can be re-addressed once CloudLinux compatibility with DirectAdmin is available and you decide to move forward with this OS

thanks and please let us know if you have any additional questions

[Bluesplinter]

That's basically what I decided, too. What I have now works very well, and I don't want to mess anything up trying to eke out another coupla ms in page load times. Lest my comments appear to be a complaint, let me assure you nothing could be further from the truth. I love my cloud server -- I'm a perfectly satisfied and happy customer. Installing scripts for my clients has become a real joy -- it all just works! :)

By the time DA is ready for Cloud Linux, you guys will also have more experience with it, and will better know what works best. I'll probably boot up a second cloud instance at that time to try CL out before deciding to migrate the production server.

Thanks much!
Steve

[Bluesplinter]

Is this viable?

http://www.cloudlinu...ctadmin_lve.php

Or would it be better to wait? In a few weeks I'm launching a large site, and I'd like to have fastcgi so I can enable APC (which doesn't work with suphp), and if I switch to CloudLinux, I'd prefer to do that before the launch (as you can imagine ).

Thanks!
Steve

[CH-Jonathan]

Hi Steve,

I'm actually testing it on one of my dev servers right now. I'll let you know :).

Bluesplinter said:

Is this viable?

http://www.cloudlinu...ctadmin_lve.php

Or would it be better to wait? In a few weeks I'm launching a large site, and I'd like to have fastcgi so I can enable APC (which doesn't work with suphp), and if I switch to CloudLinux, I'd prefer to do that before the launch (as you can imagine ).

Thanks!
Steve

[CH-Jonathan]

Hi Steve (and other interested parties),

Based on some testing - it looks like DA and CloudLinux will work together - but there appear to still be unresolved issues. However, I'm still testing -- just to make sure that it's not user error :).

More later.

[Bluesplinter]

Many thanks, Jonathan... I appreciate you doing the guinea pig dance. :D

Keep me apprised. :)

Steve

[iseletsk]

I wanted to add my 2 cents :)

Bluesplinter said:

1) Can an existing CentOS server with DirectAdmin be moved to Cloud Linux, and what impact would there be to existing sites/clients during the transition?

There should be no impact, but right now we are limited by Apache 2.2
Support for Apache 1.3 will be added within few weeks.

Bluesplinter said:

2) Does the account-level isolation mean SuPHP is no longer needed, and I can finally move to FastCGI?

LVE provides resource level limits, not security level limits -- there is no real isolation on filesystem level (yet).
On the other hand there are should be little to none difference between running suPHP or FastCGI. In both cases you run PHP as cgi under end user permissions. The main difference is that FastCGI keeps PHP loaded in memory -- and as such, faster -- but requires more RAM on the server.
Either way -- you can use LVE either way -- with the same benefits.

Bluesplinter said:

3) Since each account gets a slice of isolated resources, does that mean low-traffic sites waste resources while heavier-traffic sites starve? From what Andrew wrote, I understand that you can adjust these settings per account... but unless each site always uses exactly the same resources, then that'd have to be constantly monitored and adjusted. Or am I misunderstanding this?

No resources are wasted at all. First of all the top limit that you can set on a site (usually 20-30% on shared hosting) is just that -- top limit. It doesn't mean that site will run 20% of the time -- even if it has nothing to do.

Fair scheduling part does say that each site, no matter how heavy it is gets equal slice of CPU.
Yet, what happens is that as soon as site has nothing to do -- it yelds, stop executing, and the unused slice of CPU goes back to the pool.
So, if you have server that is just partially loaded -- each site will gets its chance, but heavy sites will be using more (up to the limit) then low-traffic site.
Even if sites use all the CPU capacity -- the site that doesn't need all the CPU in its slice will give it up, and let next site to use it asap.

[CH-Andrew]

iseletsk said:

I wanted to add my 2 cents :)

There should be no impact, but right now we are limited by Apache 2.2
Support for Apache 1.3 will be added within few weeks.


LVE provides resource level limits, not security level limits -- there is no real isolation on filesystem level (yet).
On the other hand there are should be little to none difference between running suPHP or FastCGI. In both cases you run PHP as cgi under end user permissions. The main difference is that FastCGI keeps PHP loaded in memory -- and as such, faster -- but requires more RAM on the server.
Either way -- you can use LVE either way -- with the same benefits.


No resources are wasted at all. First of all the top limit that you can set on a site (usually 20-30% on shared hosting) is just that -- top limit. It doesn't mean that site will run 20% of the time -- even if it has nothing to do.

Fair scheduling part does say that each site, no matter how heavy it is gets equal slice of CPU.
Yet, what happens is that as soon as site has nothing to do -- it yelds, stop executing, and the unused slice of CPU goes back to the pool.
So, if you have server that is just partially loaded -- each site will gets its chance, but heavy sites will be using more (up to the limit) then low-traffic site.
Even if sites use all the CPU capacity -- the site that doesn't need all the CPU in its slice will give it up, and let next site to use it asap.

Igor, thanks for jumping in here.

Everyone, I would like to formally introduce you to Igor, the CEO of CloudLinux. Igor was formally the founder and CEO of psoft (builder of the hsphere control panel). His latest project is this CloudLinux project and as you can all tell, we at Cartika are very keen on the technology Igor has brought to market and are very grateful to have him participating here in our forums. Having a direct line to an Operating System developer carries a great amount of value. Imagine being able to call up Microsoft and ask them to develop certain features or help you resolve any bugs, etc.

We very much look forward to expanding and growing our CloudLinux partnership. We are already in the process of rolling this Operating System out across our fleet of web servers and are installing Cloud Linux by default on 90% of all net new customer installs as we go along.

The technology has benefits even in environments only hosting a single domain, as container limits can be set to 95%. meaning, if "something" happens on that server (massive flood of traffic, attack, etc, etc), server admins still have 5% "management" capacity which enables them to log onto the server, figure out whats going on, and resolve the issue. Since this does not require a hard reboot, technicians have access to all of the logs and removes A LOT of guess work involved in trying to resolve an issue after a server or node requires a hard reboot.

In multi-tenant environments, the technology really shines and allows users and admins the capability to assign and allocate portions of their resources however they like. They can also set a generic size for these containers which acts as nothing more then to simply not allow a single site, for whatever reason, to take down an entire server.

We will be producing a lot more documentation on this technology as we move forward...

[Bluesplinter]

Ahh, so that explains the clear "authority" I could hear in his messages. :) He needs a sig. ;)

Thanks to both of you for your comments. I'm ready to switch as soon as Jonathan's testing with DA is complete (and you guys are ready to do that switch on my cloud server -- I don't want to interrupt your shared hosting switch-overs).

Take care,
Steve

[angel653922]

Based on some testing - it looks like DA and CloudLinux will work together - but there appear to still be unresolved issues. However, I'm still testing -- just to make sure that it's not user error .

[CH-Andrew]

DirectAdmin and CloudLinux certainly play nice together

It has been awhile since this thread was started, but, it is quite common for our customers to use CloudLinux with all *nic based control panels that we offer (directadmin, cpanel, hsphere)