UNIXy

This error is not specific to Litespeed but can be encountered while building PHP with MySQL support on 64-bit systems. The fix is to tell the build that the MySQL client is indeed installed, but in a different directory, by adding the following flag to the configure line in Litespeed:

--with-libdir=lib64

The reason being the build doesn’t know at this point that it is dealing with a 64-bit OS. If adding the above switch does not work, be sure to install the MySQL client and libraries.

That’s all folks!

Joe Break-Fix build, client, lib64, lightspeed, litespeed, MySQL, PHP

There are many types of clusters. The one I am going to cover in this post is a Web cluster. In other words, it is a cluster of several servers built to serve Web pages. It is a made up of Web servers, database servers, and file servers. You may ask, why not deploy only one server and install the Web, database, and file server? There comes a time when one single server cannot sustain the increase in traffic. The high number of visitors exceeds the capacity of the server. Be it processor power, memory availability, disk IOPS, or network IO.

Cluster

Building clusters is not for everyone. It is a complex engineering task. The complexity resides in making the whole, called cluster, accomplish the tasks efficiently and seamlessly. It becomes even more complex when one implements load balancing and database replication. Load balancing is the act of distributing tasks across two or more server with identical configurations. Database replication is the synchronization of database tables and meta data across two or more servers. Having two identical databases scales out well especially when it has been designated as the bottleneck.

Advanced Cluster

Too often I get asked, why not deploy a monster server with 32 cores and 64GB of memory instead of building a cluster? While such server might or might not sustain the traffic, there are many points that need to be thought out. The truth is such monster server is cost prohibitive. The price to value is too high and not worth it. The reason being there is currently no commodity server that can handle 32 cores. One would need a considerable budget. For much less, one can get a 32-core cluster. The other point to consider is the fact that the motherboard bus will not be able to sustain the throughput required for a high traffic server. It will not be able to seamlessly pull 64GB/s in and out of the memory system.

Another important point is disaster recovery, one would need another equally powerful server or a very aggressive (read extremely expensive) part-replacement contract. On the other hand, commodity hardware is so affordable one could keep a few spares without breaking the bank! Plus, a monster server will never handle Digg or Slashdot effects. The cluster, however, can scale to accommodate for traffic spikes.

Keep in mind that UNIXy builds clusters for current customers free of charge. The support and service is included with your purchased dedicated servers. Contact us today and we will go above and beyond to help out.

That’s all folks!

Joe Challenge cluster, database, dedicated cluster, replication, synchronization, UNIXy, web cluster, web server

There are a few server-grade processors in the market. The well-know ones are Intel Xeon, AMD Opteron, Intel Itanium, and Sparc. Core2Quad and Phenom are, for example, desktop CPUs. There is confusion as to what makes a server-type CPU different from a desktop counterpart. Besides the bus speed improvement, there is a fundamental difference that proves to be important especially if there is a lot at stake. At UNIXy, all servers we promote to production are either Intel Xeon or AMD Opteron processors. We have to offer the best quality components to our customers.

Before we delve into the main differences, there is one element that makes server processors stand out from the rest: validation. It is about the effort spent validating processors that differentiates desktop from server CPUs. As an analogy, it makes perfect sense that a passenger aircraft engine would require much more stringent validation than a car engine. The risk is undoubtedly higher for an aircraft engine. The same applies to server processors. A desktop processor is designed to cater to the needs of one person. On the other hand, there is much more at stake with a server processor!

Let us cover each point one by one.

Validation

Server processors are put through all kinds of tests under stressful conditions such as higher temperatures, strict environmental conditions, and high computing loads. The time spent performing these tests increases the costs and time to delivery considerably.

Dependable

Server processors are designed for reliability. For example, if your desktop processor were to somehow fail, the whole workstation becomes inoperable. Server CPUs have the smarts to be able to failover, in the case of a dual CPU server, without having to crash or shutdown. Granted, one would have to have a dual CPU configuration. It is important to note that desktop CPUs do not support dual processor configurations.

Self Correcting

Server processors have the circuitry in place to correct memory errors that can affect stability. The technology is called Error Code Correction (ECC). Some desktop configurations are also capable of ECC but the feature is not validated as is the case with server CPUs. Hence, my stressing the importance of validation first and foremost.

Higher trafficking

Server CPUs are designed with buses that operate at much higher frequencies (bandwidth). This means that they can process more data in and out of memory and other subsystems. Heat can be a concern for these buses as it impedes the flow of electricity and hence throughput. This is why server-grade processors have their matching powerful fan blowers.

That’s all folks!

Joe Business core2quad, desktop CPU, server CPU, server desktop difference, validation, xeon vs opteron

Houston does it for the first time on record. It is snowing like there’s no tomorrow!

Cheers!

Joe Interesting

My interest in NUMA (Non-Uniform Memory Access) has picked up quite a bit as of late. This technology has a huge potential for application in large scale Web hosting and Internet solutions. In brief, NUMA is a technology that was conceived to get around bus contention in general. What this means is that, with NUMA, programs are no longer limited by memory size or disk IOPS on the same host node and can, therefore, harness the power of other nearby servers as if they were part of the same chassis. In fact, IO scales up as a result!

The problem with uniform memory access architectures is that in a single chassis multi-processor system with a large amount of memory the bus tends to saturate very quickly. Processor cores addressing the memory bus are thus contending for the same resource, which becomes a hot spot. Take a 32-core server with 128GB of DDR3 memory. This server will under perform should it run a parallel memory hungry application. The issue being that each task on a core will at some point need to address memory via the bus (DDR3 is a three-frequency or three-channel bus). So out of 32 tasks that are all attempting to access the bus, there will be (32 -3 = 29/3 ~ 9) 9 tasks that contend for the same channel. The end result is a saturated bus and poor performance.

NUMA solves this bus contention problem by creating a virtual network of processor nodes and giving each node a certain weight based on its locality. The most interesting aspect is its true scalability potential. Most importantly, NUMA is the only technology that can scale up. Amazon’s EC2 and most other technologies in the market nowadays can only scale out. In other words, one has to implement load balancing, replication, and data synchronization.

Here’s where it gets interesting. IBM has already comoditised NUMA with its x86 offering: the IBM x440. Although one can only chain two x440 chassis together to form one NUMA network, what was once a concept is now practical! The x440’s can be chained together via their SMP expansion module using remote IO cables. Now imagine having the ability to chain 5, 10, 100 16GB dual quad core boxes! Not only does one take advantage of of a few terrabytes of memory but also scale core compute and IO.

A challenge remains. The remote IO cables that allow formation of a NUMA node cluster is based on proprietary technology. The research and development effort required to deliver such technology is colossal for a smaller firm. Or maybe not!

Joe Future Amazon EC2, bottleneck, cloud, EC2, nehalem, NUMA, rackspacecloud