I moved my sites from a dedicated to a cloud system, mostly because I wasn't using hardly any of the dedicated server. I have one forum that is active, but not more than 100 users on at a time.

I've upgraded the cloud system to BETTER specs than I had on my old dedicated box and am having serious issues with mysql queries taking FOREVER. I'm wondering if it's an issue with the cloud set up or what.

iowaits % is in the 20 to 75 range with loads running from 3 to 25.

on my old dedi i didn't see loads over 1 unless i was running backups.

Appreciate the input guys.

Thanks

I moved my sites from a dedicated to a cloud system, mostly because I wasn't using hardly any of the dedicated server. I have one forum that is active, but not more than 100 users on at a time.

I've upgraded the cloud system to BETTER specs than I had on my old dedicated box and am having serious issues with mysql queries taking FOREVER. I'm wondering if it's an issue with the cloud set up or what.

iowaits % is in the 20 to 75 range with loads running from 3 to 25.

on my old dedi i didn't see loads over 1 unless i was running backups.

Appreciate the input guys.

Thanks

yup - you might need to look at a cloud host that has a tiered storage system that can provide enough IO for your forum.

Crappy! :( it's one of the more respected hosts around here too.... maybe i wasn't "ready for the cloud".

if you let us know what host it is we may be able to suggest ideas on that basis.

100 users online isn't very many at all - good quality shared hosting can handle that.

The one thing I would say is that if you have a large database and not enough RAM to actively cache the vast majority of what is in the database then MySQL is going to be attempting lots of writes to disk. On a shared SAN this can often lead to IO wait and thus poor performance. Two options here - you can try tweaking your my.cnf to make better use of the memory available to MySQL, you can increase your RAM on your virtual server, or you can find a solution where disk I/O isn't so poor.

I moved my sites from a dedicated to a cloud system, mostly because I wasn't using hardly any of the dedicated server. I have one forum that is active, but not more than 100 users on at a time.

I've upgraded the cloud system to BETTER specs than I had on my old dedicated box and am having serious issues with mysql queries taking FOREVER. I'm wondering if it's an issue with the cloud set up or what.

iowaits % is in the 20 to 75 range with loads running from 3 to 25.

on my old dedi i didn't see loads over 1 unless i was running backups.

Appreciate the input guys.

Thanks
Its better you ask the provide about the cloud setup before sign up. Most Cloud are setup with common SAN for HA. If the SAN is not performing very good, you might end up with I/O issues.

Is your host using a SAN, or local storage? I definitely see this being more common on SAN's as many Cloud hosts will fill half a dozen servers or so per group of redundant SAN's, so as you can see it's a bit of a bottleneck as CPU density is good, but IO takes a beating as there's a lot of demand on it.

Have you asked your host what the story is and if any improvements can be made?

It's SAN based.

I'm just trying to determine if it's a database issue or server issue. I have two forums on the server, one has a very small db and runs fine. The host has done a great deal of "tweaking" to the server and the large forum runs fine EXCEPT when you go to make a post or delete a post ie, make changes to the database. The database for the forum i am having the issue on 3.5 gigs, it literally takes 3 to 5 minutes to make a post to the forums.

I've tried moving the forum several ways, with a sql dump ad rsyncing the entire db from the old server. The specs on the dedi were 2 cores, 4 gigs memory and I never had load issues or post issues. The specs on the new server are 4 cores, 4 gigs memory. Memory is sitting fairly maxed out and as i type this iowait is 98 cpu usage is 1% and the load on the server is 35!!!!!

Clearly something is not right, I just hate to bail after moving all my data to find out it's an issue with the db i moved and not the server, but I can't see the db being bad, if it were bad it would spit errors and it isn't, it's just taking forever to INSERT and SORT.

thanks guys!

For starters, 4 cores vs 2 cores doesn't mean better. What processor's did you go from, and what are you on now? What about memory? What speed is it? Also there is some small overhead (and in come crappy software, large overhead) with cloud.

The DB isn't exactly small, but it's not huge either. Be sure you're comparing apples-to-apples with the infrastructure first as you could just as easily find out you went from a much faster processor with half the core's, to a much slower processor with twice the core's still giving you a true end result of 50% of the performance you were used to. Also it's imperative to know if that is truly dedicated core's and not shared or oversold. Ie: what virtualization technology is this cloud built on? Xen?

That's just some food for thought but since you are seeing low CPU usage and high IOWAIT it points to an IO issue. Server load will go up as commands are being queue'd as they cannnot be processed. Load is an indicator of the workload so other tasks that are less IO intensive could actually still load quickly in that state.

Have you done benchmarks to see what your IO numbers are? I am curious how fast you can get. That should help you determine if it's a hosting problem, or a problem with your application.

i haven't done benchmarks, I am not seeing large processor loads, but the processors are same type, intel and the ones are slightly faster (not much) so it should be apples to apples there. The memory I will have to take a look at.

it is xen and it is dedicated cores, according to their website.

It seems clear that their SAN setup is not working out for you with that kind of iowait.

I'd be interested in knowing which provider this is?

From the hdparm:
Buffered disk reads: 186MB in 3.01 seconds = 61.74 MB/sec
Timing cached read 2528 MB in 2 seconds = 11339.82 MB/sec

I don't want to throw the host under the bus as I have yet to determine if it's a server issue or an issue with the db. They've done a great deal to try and get the issue under control and it's gotten better, but still not usable.

Use dd for a more accurate reading on how fast you can actually write to the disks. (note this will only measure sequential write performance of course)

dd if=/dev/zero of=ddfile bs=8k count=512000

270927+0 records in
512000+0 records in
512000+0 records ou
4194304000 bytes (4.2 gb) copied, 121.069 seconds, 34.6M

For comparison, here is the output of the same command on Voxel.net's cloud, approximately 3x faster:


# dd if=/dev/zero of=ddfile bs=8k count=512000
512000+0 records in
512000+0 records out
4194304000 bytes (4.2 GB) copied, 39.3221 seconds, 107 MB/s

Gigenetcloud (also does better):


$ dd if=/dev/zero of=ddfile bs=8k count=512000
512000+0 records in
512000+0 records out
4194304000 bytes (4.2 GB) copied, 42.6304 s, 98.4 MB/s

It's definetly a server/disk IO issue. I highly doubt tweaking it will solve it but even if it did there is something wrong with the storage setup there. I am sure your host can solve it but not by tweaking your OS.

It's definetly a server/disk IO issue. I highly doubt tweaking it will solve it but even if it did there is something wrong with the storage setup there. I am sure your host can solve it but not by tweaking your OS.

Actually, it's inherently in the design. There is nothing to "solve" as it is a design problem. What's sad is the host is probably using SAS drives in a shared SAN. If you stick a half a dozen servers (I am totally guessing at that, it could even be more from what I've seen of other companies) on one storage device, your IO goes to crap. They may have great CPU density and be able to provide great platforms for computing but when there's a few heavy DB users the whole mini-cloud (those using SAN's are usually building groups of mini-clouds) goes to crap.

That speed for writing was one third the speed of a standard single SATA drive. Given the load.. I just tested some of our fully loaded SATA nodes and they averaged 80MB/s using the same dd test.

You can polish a turd, but it's still a turd.

For cloud, local storage > SAN. Independant studies have shown this time and time again. Only those hosts that are clearly underloaded and not near capacity (or like wasting money in tons of very high-end SANs and using them on very few servers) do well with IO.

That speed for writing was one third the speed of a standard single SATA drive. Given the load.. I just tested some of our fully loaded SATA nodes and they averaged 80MB/s using the same dd test.

After some researching, testing and doing benchmarks I've come to the conclusion that comparing large sequential read/write doesn't necessarily correlate to MySQL performance, better to use a tool like IOzone that benchmarks various file and block sizes.

Example using read/write of 1 Gig file and MYSQL's benchmark tool

VPS with local SCSI in RAID10 (16 CPU share)
Write: 483 MB/s
Read: 1.5 GB/s
MySQL Benchmark Total: 1123 sec

XEN VPS using SAN (1 CPU)
Write: 228 MB/s
Read: 62 MB/s
MySQL Benchmark Total: 890 sec

Well just running iozone spiked my server load from 1.09 to 14.89... good stuff.

I don't get any numbers like you mentioned however.

IOzone, like any benchmarking tool, will put a load on the server

The results I posted above are not from IOzone, this however is
http://www.digiscape.com.au/benchmark/Random-Read-Write-IOZone.pdf

SV1 & SV2 are VPS's with local attached drives, others use a SAN

After some researching, testing and doing benchmarks I've come to the conclusion that comparing large sequential read/write doesn't necessarily correlate to MySQL performance, better to use a tool like IOzone that benchmarks various file and block sizes.

Example using read/write of 1 Gig file and MYSQL's benchmark tool

VPS with local SCSI in RAID10 (16 CPU share)
Write: 483 MB/s
Read: 1.5 GB/s
MySQL Benchmark Total: 1123 sec

XEN VPS using SAN (1 CPU)
Write: 228 MB/s
Read: 62 MB/s
MySQL Benchmark Total: 890 sec

Why would the read performance be slower than write in that second setup?

Why would the read performance be slower than write in that second setup?

I get have similiar results with different cloud providers, you would think write would be slower as they all use some form of RAID and writing to multiple SANS for redundancy

Actually, it's inherently in the design. There is nothing to "solve" as it is a design problem. What's sad is the host is probably using SAS drives in a shared SAN. If you stick a half a dozen servers (I am totally guessing at that, it could even be more from what I've seen of other companies) on one storage device, your IO goes to crap. They may have great CPU density and be able to provide great platforms for computing but when there's a few heavy DB users the whole mini-cloud (those using SAN's are usually building groups of mini-clouds) goes to crap.

That speed for writing was one third the speed of a standard single SATA drive. Given the load.. I just tested some of our fully loaded SATA nodes and they averaged 80MB/s using the same dd test.

You can polish a turd, but it's still a turd.

For cloud, local storage > SAN. Independant studies have shown this time and time again. Only those hosts that are clearly underloaded and not near capacity (or like wasting money in tons of very high-end SANs and using them on very few servers) do well with IO.

Actually that is kind of my point :rolleyes: the provider has to solve their crappy design. I should have been more direct I guess. My point was the same as yours no amount of OS tuning is going to resolve it only possibly mask it for a bit.

This provider needs to review it's storage architecture and "solve" it by changing it.

edit: I should say that a properly designed SAN architecture should not have this problem even with 10 or 20 hosts attached. It isn't that SAN's can't handle this, SAN's handle all kind of much higher volumes in different environments.

Remember, a SAN is not just a "san", some of them are build with 2tb 5400 rpm HD's, others with fusionIO ramdisks, so you can not generalize by saying that "local storage > SAN" - it is not that simple.

:)
D

Remember, a SAN is not just a "san", some of them are build with 2tb 5400 rpm HD's, others with fusionIO ramdisks, so you can not generalize by saying that "local storage > SAN" - it is not that simple.

:)
D

Of course, but in most cloud providers it's not practical at least for mass marketing to the general public. Just based on some independent tests that I've seen like this one (http://blog.cloudharmony.com/2010/06/disk-io-benchmarking-in-cloud.html) most providers are seeing better IO results using local vs SAN. The reason of course is not technical that local can beat out SAN, as obviously SAN's have the capability to technically outperform local storage. The problem comes into play when you consider economics.

I'm in the process of building a cloud right now with some very high end enterprise ssd drive's using local storage. We're actually migrating the customer away from 2x external RAID10 15K SAS SAN's. I would not go and put that on for my shared hosting platform though as it's cost prohibitive. If I was doing enterprise ssd's with 2x redundant SAN's then the cost goes up even higher. With local storage we have a cheaper, faster, scalable, and a more reliable infrastructure. You can add servers as fast as you can add them, and increase your storage as fast as you can add servers. If you build cloud's around SAN's you will eventually hit a wall, it costs more, and it's more complicated.

For larger customers that have an entire VPDC built, you can build that around their needs and SAN's can still make sense in a few situations (we still have a few in use), but we simply look at the whole picture and make a decision based on the facts. Unfortunately for SAN's, in most cases it is not working in it's favor any more.

I'm going to test gigenet's cloud and see if it will work, if not it's back to my dedi. I'll let you guys know when i get to testing.

Would be very interested to see your results.

Initial observations. Unpack the cpmove file on cloud 1, 4+ hours (don't know I went to sleep after 4 and it was done when I got up). Unpack the same cpmove file on Gigenet 1 hour 20 mins.

That seems about in line with the sequential disk I/O performance shown via 'dd' on the last page.

The numbers shown here seem very much out of line with what one would expect from a SAN type of solution - and as layer0 and others have indicated, it seems likes an engineering problem more then anything... I also would be very curious to know which provider you are talking about, but, I respect your intention of finding a solution vs throwing a provider under the bus.. Having said this, some fundamentals here are not being accounted for..

Of course, but in most cloud providers it's not practical at least for mass marketing to the general public. Just based on some independent tests that I've seen like this one (http://blog.cloudharmony.com/2010/06/disk-io-benchmarking-in-cloud.html) most providers are seeing better IO results using local vs SAN. The reason of course is not technical that local can beat out SAN,

Well, absolutely local storage will beat out SAN storage - especially for DB functionality - whether that be MySQL, MSSQL, etc.. but, a local storage VM, is basically a VPS.. add a fancy billing portal, and I guess you have a VPS with more granular billing - but, a cloud it is not - it will lack redundancy and it will lack fluidity to move instances between physical nodes...

as obviously SAN's have the capability to technically outperform local storage. The problem comes into play when you consider economics.

this is not a question of economics. Going external for DB calls will carry an inherit "lag" - this has been true forever with clustering technologies, load balancing, etc.. it is no different here. The "Cloud" is a wonderful technology - and will continue to grow and develop - but, no one would recommend running heavy DB instances on a cloud configuration with data offloaded to a SAN. Heck, even MySQL and MSSQL are working towards solutions in future versions to make their products more compliant with this architecture...

For larger customers that have an entire VPDC built, you can build that around their needs and SAN's can still make sense in a few situations (we still have a few in use), but we simply look at the whole picture and make a decision based on the facts. Unfortunately for SAN's, in most cases it is not working in it's favor any more.

you simply need t choose the right tools for the right job. The "whole" picture dictates that you look at requirements and determine which solutions make sense for which services.. A local storage model makes the most sense for DB services, as the various common frameworks (mysql and MSSQL) are not yet ready for offloading services to non local storage. Having said this, web services and light to average DB services are ideally suited for the cloud.

Now the particular poster here should have zero issue hosting their DB on the cloud - honestly, their usage is nominal and unless something is really wrong with their DB and code where they are flooding requests to the SAN, they should have no issue what so ever. But, for very large customers, who have heavy DB requirements - the absolute best solution is to split their requirements. So, put them on a cloud based solution for their web services and a local storage solution for their DB services - cluster within the cloud if you like - with specialized architecture for their respective services...

I'm going to test gigenet's cloud and see if it will work, if not it's back to my dedi. I'll let you guys know when i get to testing.

no reason for that - you can get a cloud based web service + a local storage MySQL service. Your costs will be significantly less then a dedicated server, you will gain redundancy and elasticity for your web service and your MySQL service will be running on a local storage model. A simple and effective cluster within the cloud will resolve your issue. Though, with your requirements, honestly, this should not even be required. Any good cloud solution will meet your requirements...

Well, absolutely local storage will beat out SAN storage - especially for DB functionality - whether that be MySQL, MSSQL, etc.. but, a local storage VM, is basically a VPS.. add a fancy billing portal, and I guess you have a VPS with more granular billing - but, a cloud it is not - it will lack redundancy and it will lack fluidity to move instances between physical nodes...

I never said "local storage" only resides on one server, and is not pooled together onto multiple servers creating a "virtual SAN" if you will. The data is simply created by using local storage on the servers in the cloud. HA and redundancy it has, and it's irrelevant if the application is accessing data on that same physical server, or another one. It is cloud.


this is not a question of economics. Going external for DB calls will carry an inherit "lag" - this has been true forever with clustering technologies, load balancing, etc.. it is no different here. The "Cloud" is a wonderful technology - and will continue to grow and develop - but, no one would recommend running heavy DB instances on a cloud configuration with data offloaded to a SAN. Heck, even MySQL and MSSQL are working towards solutions in future versions to make their products more compliant with this architecture...

If it's a small DB cloud that is connected directly to the SAN just as a non-cloud infrastructure, it's not really an issue. But I do agree, it's not always economics but unfortunately in this market for many small companies that is a focus so spending twice as much on a storage infrastructure is a tall order.


you simply need t choose the right tools for the right job. The "whole" picture dictates that you look at requirements and determine which solutions make sense for which services.. A local storage model makes the most sense for DB services, as the various common frameworks (mysql and MSSQL) are not yet ready for offloading services to non local storage. Having said this, web services and light to average DB services are ideally suited for the cloud.

Now the particular poster here should have zero issue hosting their DB on the cloud - honestly, their usage is nominal and unless something is really wrong with their DB and code where they are flooding requests to the SAN, they should have no issue what so ever. But, for very large customers, who have heavy DB requirements - the absolute best solution is to split their requirements. So, put them on a cloud based solution for their web services and a local storage solution for their DB services - cluster within the cloud if you like - with specialized architecture for their respective services...

no reason for that - you can get a cloud based web service + a local storage MySQL service. Your costs will be significantly less then a dedicated server, you will gain redundancy and elasticity for your web service and your MySQL service will be running on a local storage model. A simple and effective cluster within the cloud will resolve your issue. Though, with your requirements, honestly, this should not even be required. Any good cloud solution will meet your requirements...

Or a cloud based service that utilizes local storage so MySQL is also HA/redundant. :D

I never said "local storage" only resides on one server, and is not pooled together onto multiple servers creating a "virtual SAN" if you will. The data is simply created by using local storage on the servers in the cloud. HA and redundancy it has, and it's irrelevant if the application is accessing data on that same physical server, or another one. It is cloud.

OK - I understand what you are saying. I think we have a difference in understanding around some terms here. What you are describing is not "local" storage - it is simply a way of managing storage to overcome architecture. Once the data request leaves the physical server, it is no longer "local" - at least by my definition. Once this happens, there are certain characteristics which must be accounted for. The issue you are describing is not with "virtual sans" - as essentially, you are still doing the same thing, just limiting the potential load on each physical SAN via architecture. The "correct" way to do this - again, at least in my opinion - is to use the right tool for the right job. Enterprise grade SANs (ie EMC, NetAPP, etc) bi-pass these issues - in that you can add throughput/IOPs/Spindles, etc as required, and in a proactive and practically infinite manner - so as to avoid IO issues. Again though, no matter the architecture, the Cloud is not yet ideal for very very heavy DataBase configurations. Enterprise grade sites, or sites/services with VERY high DB usage are still "stuck" on using local storage models. For this customer, or any customer for that matter using a dedicated server of resources or less - a good cloud is a perfect solution to achieve elasticity and redundancy. But, very very large installs, are still limited by the inherit limitations of platforms like MySQL and MSSQL - and these customers will need to utilize a combination of the Cloud for web services and traditional nodes with replication or clustering of the DB service in order to achieve High Availability of that specific service


If it's a small DB cloud that is connected directly to the SAN just as a non-cloud infrastructure, it's not really an issue. But I do agree, it's not always economics but unfortunately in this market for many small companies that is a focus so spending twice as much on a storage infrastructure is a tall order.

Agreed - and the costs for a real storage platform that can accommodate these requirements is likely more then double the cost. But, those costs need to be reflected in the price of the service offering. This is no different then any other hosting model - there will be a separation in the market over price, and that separation will be indicative of the quality of the infrastructure and service provided. I guess it depends on each provider with where they want to play and what type of service they want to offer and what type of customer they want to offer


Or a cloud based service that utilizes local storage so MySQL is also HA/redundant. :D

Well again, for this customer, with this sort of requirement - a cloud based service, with a "proper" SAN architecture will more then fit their needs and still allow them to have HA for all services without getting overly complex. For very large customers, no matter what architecture you have on the cloud, you would be doing your customer a dis-service recommending a cloud based solution for DB services. The best solution for these customers is to use the cloud for web based services, and traditional, local storage nodes (VPS or Dedicated) for DB services (replicated or clustered in order to achieve HA)

Excellent conversation!

thanks :)

OK - I understand what you are saying. I think we have a difference in understanding around some terms here. What you are describing is not "local" storage - it is simply a way of managing storage to overcome architecture. Once the data request leaves the physical server, it is no longer "local" - at least by my definition. Once this happens, there are certain characteristics which must be accounted for. The issue you are describing is not with "virtual sans" - as essentially, you are still doing the same thing, just limiting the potential load on each physical SAN via architecture. The "correct" way to do this - again, at least in my opinion - is to use the right tool for the right job. Enterprise grade SANs (ie EMC, NetAPP, etc) bi-pass these issues - in that you can add throughput/IOPs/Spindles, etc as required, and in a proactive and practically infinite manner - so as to avoid IO issues. Again though, no matter the architecture, the Cloud is not yet ideal for very very heavy DataBase configurations. Enterprise grade sites, or sites/services with VERY high DB usage are still "stuck" on using local storage models. For this customer, or any customer for that matter using a dedicated server of resources or less - a good cloud is a perfect solution to achieve elasticity and redundancy. But, very very large installs, are still limited by the inherit limitations of platforms like MySQL and MSSQL - and these customers will need to utilize a combination of the Cloud for web services and traditional nodes with replication or clustering of the DB service in order to achieve High Availability of that specific service

Gotcha, and I completely agree! Especially for LARGE databases (those that are using high-end SAN's, EMC's and the like) obviously these standard servers won't fly. The one we're building using enterprise grade ssd drives will be pretty good, and serve a fairly large database, but obviously nothing to the extremes that a truly large infrastructure would require. I use the word "local" as so many others use the word to show that Cloud's can be built using storage inside of each server in that cloud, and they don't have to be built solely on external SAN's (for example, only booting off a local/internal drive and then accessing the data on an external SAN for all applications).

Agreed - and the costs for a real storage platform that can accommodate these requirements is likely more then double the cost. But, those costs need to be reflected in the price of the service offering. This is no different then any other hosting model - there will be a separation in the market over price, and that separation will be indicative of the quality of the infrastructure and service provided. I guess it depends on each provider with where they want to play and what type of service they want to offer and what type of customer they want to offer

Absolutely. :agree:


Well again, for this customer, with this sort of requirement - a cloud based service, with a "proper" SAN architecture will more then fit their needs and still allow them to have HA for all services without getting overly complex. For very large customers, no matter what architecture you have on the cloud, you would be doing your customer a dis-service recommending a cloud based solution for DB services. The best solution for these customers is to use the cloud for web based services, and traditional, local storage nodes (VPS or Dedicated) for DB services (replicated or clustered in order to achieve HA)

Excellent conversation!

thanks :)

Agreed.. I will also be putting up a thread eventually once we get this cloud built and operational for this particular customer using the enterprise ssd drives with "local" (virtual SANs or whatever we want to call them). There's a dozen node's in it so It's a pretty big site and it should be a good case study as it's fairly DB intensive. Although obviously not intensive enough to justify the need of an EMC or other very high-end SAN solution.

OK just some initial results.

I am up and running on the gigenet cloud and the site is quite snappy. All of the issues I was running into on the first cloud are gone.

I've found gigenet's cloud and support so far to be top notch. Their control panel for the cloud set up is strait forward, easy to use and it works. Creating a cloud takes maybe 5 minutes. I am not having the i/o wait issues or high server loads and I'm using HALF the ram I was using on the first cloud! I think the only thing I found confusing was the "credits" system. I don't really understand the necessity for it and it's a little awkward at first. I find myself converting to dollars anyhow, so what's the point?

Disk read and write is 1/4 to 1/5th the times I was seeing on the previous cloud....now everyone wants to know who the initial host was and I am very reluctant to throw them under the bus even though I have pretty much proven it's an issue with their setup and not my db. My logic for this is; I have had dedicated servers with this host in the past and found their datacenter and support to be top notch, not one complaint and even in this instance their support was phenomenal. Furthermore the rest of the websites on the server ran quite well on their cloud, so I really hate to give them a bad rap when they haven't really "done me wrong".

so I really hate to give them a bad rap when they haven't really "done me wrong".

Class act phinsup - wish there were more like you

I'm glad to hear Gigenet's cloud is working well for you. I've thoroughly tested their platform for disk I/O performance and it is indeed ahead of the rest.

Thanks for the follow-up. You should at least let the old host know of your thoughts now as that is the kind of feedback they need to know how to improve their service. That's the kind of problems that could run the company into the ground if they start pushing Cloud heavily and it's an inferior implementation of it.

I opened a ticket and let them know the results of my tests and that they do have some issues that need to looked into.

I definitely appreciate all the help given to me here, you guys helped me put an end to a frustrating problem. I will post a full review on how gigenet's cloud is working for me as I get a longer track record. Obviously it's too soon to tell if it's the right fit or not, but so far so good.

So... who was the provider?

So... who was the provider?

As I stated before I don't feel comfortable posting the provider's name here. I think for most cases their service will work fine for hosting websites as long as they aren't dealing with large mysql db's I think my case was a special one as I have a 4 gig Mysql db. Furthermore, their tech support made every effort to rectify the situation and I have a hard time throwing someone under the bus when they treated me right. The provider had a coupon and therefor I am out no money... only some time and I think that it would be inappropriate for me to drag them through the mud when they haven't "screwed me" in any way.

IF, you have a large forum and are in a similar situation as I was, please feel free to PM me and I will give you the details on the host so that you can avoid an outcome such as mine, otherwise I feel like I would be doing the host and the community a disservice if I were to post the hosts name here for all to see.

As I stated before I don't feel comfortable posting the provider's name here. I think for most cases their service will work fine for hosting websites as long as they aren't dealing with large mysql db's I think my case was a special one as I have a 4 gig Mysql db. Furthermore, their tech support made every effort to rectify the situation and I have a hard time throwing someone under the bus when they treated me right. The provider had a coupon and therefor I am out no money... only some time and I think that it would be inappropriate for me to drag them through the mud when they haven't "screwed me" in any way.

IF, you have a large forum and are in a similar situation as I was, please feel free to PM me and I will give you the details on the host so that you can avoid an outcome such as mine, otherwise I feel like I would be doing the host and the community a disservice if I were to post the hosts name here for all to see.

This is a very admirable approach to take. :agree:

While it does help the community to name the provider hopefully they will get the kinks worked out.

Well, absolutely local storage will beat out SAN storage - especially for DB functionality - whether that be MySQL, MSSQL, etc.. but, a local storage VM, is basically a VPS.. add a fancy billing portal, and I guess you have a VPS with more granular billing - but, a cloud it is not - it will lack redundancy and it will lack fluidity to move instances between physical nodes...

I agree, but I just wanted to point out that you can still move VMs from one server to another (with local storage), it would just require doing a full migration (storage included) rather than just unmounting and remounting central storage. Quite honestly the main thing you lose is redundancy by not going for a central storage solution. This is obviously a very important thing, but for certain applications I think performance is more important. Moreover, you can still easily achieve 99.99% average uptime with a proper local storage setup.

I agree, but I just wanted to point out that you can still move VMs from one server to another (with local storage), it would just require doing a full migration (storage included) rather than just unmounting and remounting central storage. Quite honestly the main thing you lose is redundancy by not going for a central storage solution. This is obviously a very important thing, but for certain applications I think performance is more important. Moreover, you can still easily achieve 99.99% average uptime with a proper local storage setup.

Not really going to disagree. We sell both solutions ourselves for a reason ;)

As I have been continually spouting on about - the right tools for the right jobs. And typically, the right solution involves a combination of multiple tools.

Worth mentioning however, a manual migration is not really the same as a fluid movement of an instance from one physical node to another - whether that be because of hardware failure, capacity reasons, etc..

also, it is very difficult, if not impossible, to SLA a 99.99% SLA on single server infrastructure. Though I agree that 99% of the time, you should be able to achieve 99.99% uptime - it is an impossible metric to consistently maintain on single servers - which is ultimately what is driving the innovation towards clouds, grids, etc, etc..

End of the day though, I completely agree with you - an environment that is solely reliant on performance, should probably look to local storage solutions over anything where data is offloaded to SANs, etc - it is only natural that a backplane will handle things more efficiently then GIG or 10G or even fiber transit and iSCSI protocol. Having said this, the best solution is still a hybrid approach of all technologies - build a specialized services cluster - cloud for web service, local storage for DB service - and if you want HA all around, add in a 2nd local storage "node" for DB service and utilize replication, etc...

all of this is of course budget driven - and is exactly why cloud solutions are so popular right now - it is the easiest and most cost effective way to get the best of both worlds - and the only sacrifice is a small hit in performance - and in 90% or more of the scenarios, the difference is not even noticeable..