Sponsored Content
Special Forums UNIX and Linux Applications High Performance Computing High reliability web server - cluster, redundancy, etc Post 302301982 by bsaadmin on Sunday 29th of March 2009 04:29:48 PM
Old 03-29-2009
High reliability web server - cluster, redundancy, etc

Hi. I am IT manager/developer for a small organization. I have been doing as-needed linux server administration for several years and am by no means an expert. I've built several of my own servers, and our org is currently using hosting services for our servers and I am relatively happy.

We recently had an outage at the host, and management has made clear that this is unacceptable. Our host is one of the larger ones, a publicly traded company, and their techs are onsite and knowledgeable. The outage was a problem with the pipe between the hosting company and the backbone to the internet, caused by the hosting company's pipe provider. It lasted about 25 minutes. Just FYI.

So the conversation about redundancy and clusters has begun. I have never done this before. My hosting company offers a cluster plan that would be easy to implement (CPanel based) but that won't solve the problem of a pipe outage. We are thinking of clustered web servers (apache, php) and clustered databases (mysql) in different locations geographically. Wha are the considerations involved? Rough idea of costs, risks that remain, etc.

Any direction would be really appreciated.
 

3 More Discussions You Might Find Interesting

1. Solaris

High Availability zone on Sun Cluster

HI Experts, Could some one help me in configuring high availability zone on Sun Cluster Reg: Sudhan (3 Replies)
Discussion started by: sudhan143
3 Replies

2. Red Hat

Red Hat High Availability (HA) Cluster

How can we implement a service in HA, which in not available in HA. like sldap or customize application. Requirement Details. NODE1 service slapd is running.(Require) NODE2 service slapd is running.(Require) on both the node replication is happening. Now here requirement is need... (2 Replies)
Discussion started by: Priy
2 Replies

3. Red Hat

Web server cluster at some point ?

What's the best way clusters for Storage at some point? (The way that data is the same in all parts) To set up a Web server cluster is the logical way?! Cluster database and Storage and then by keepalived + HA cluster will be communicated? Or, there a better solution? (For about 4 points) Thank... (0 Replies)
Discussion started by: mnnn
0 Replies
Catalyst::Manual::Deployment(3pm)			User Contributed Perl Documentation			 Catalyst::Manual::Deployment(3pm)

NAME
Catalyst::Manual::Deployment - Deploying Catalyst DEPLOYMENT OPTIONS
Catalyst applications are most often deployed as a FastCGI or mod_perl application (with FastCGI being the recommended option). However, as Catalyst is based on the PSGI specification, any web handler implementing that specification can be used to run Catalyst applications. This documentation most thoroughly covers the normal and traditional deployment options, but will mention alternate methods of deployment, and we welcome additional documentation from people deploying Catalyst in non-standard environments. Deployment in a shared hosting environment Almost all shared hosting environments involve deploying Catalyst as a FastCGI application on Apache. You will usually want to have a set of libraries specific to your application installed on your shared host. Full details of deploying Catalyst in a shared hosting environment are at Catalyst::Manual::Deployment::SharedHosting. FastCGI FastCGI is the most common Catalyst deployment option. It is documented generally in Catalyst::Manual::Deployment::FastCGI, and there are specific instructions for using FastCGI with common web servers below: Apache Catalyst::Manual::Deployment::Apache::FastCGI nginx Catalyst::Manual::Deployment::nginx::FastCGI lighttpd Catalyst::Manual::Deployment::lighttpd::FastCGI Microsoft IIS Catalyst::Manual::Deployment::IIS::FastCGI mod_perl Traditionally a common deployment option for dedicated applications, mod_perl has some advantages and disadvantages over FastCGI. Use of mod_perl is documented in Catalyst::Manual::Deployment::Apache::mod_perl. Development Server It is possible to deploy the Catalyst development server behind a reverse proxy. This may work well for small-scale applications which are in an early development phase, but which you want to be able to show to people. See Catalyst::Manual::Deployment::DevelopmentServer. PSGI Catalyst can be deployed with any PSGI-compliant handler. See Catalyst::PSGI for more information; a list of possible deployment servers are shown below: Starman Starman is a high-performance Perl server implementation, which is designed to be used directly (rather than behind a reverse proxy). It includes HTTP/1.1 support, chunked requests and responses, keep-alive, and pipeline requests. Starlet Starlet is a standalone HTTP/1.0 server with keepaXXalive support which is suitable for running HTTP application servers behind a reverse proxy. Twiggy Twiggy is a high-performance asynchronous web server. It can be used in conjunction with Catalyst, but there are a number of caveats which mean that it is not suitable for most deployments. Chef <LChef|http://www.opscode.com/chef/> is an open-source systems integration framework built specifically for automating cloud computing deployments. A Cookbooks demonstrating how to deploy a Catalyst application using Chef is available at <http://community.opscode.com/cookbooks/catalyst> and http://github.com/melezhik/cookbooks/wiki/Catalyst-cookbook-intro <http://github.com/melezhik/cookbooks/wiki/Catalyst-cookbook-intro>. AUTHORS
Catalyst Contributors, see Catalyst.pm COPYRIGHT
This library is free software. You can redistribute it and/or modify it under the same terms as Perl itself. perl v5.14.2 2012-01-20 Catalyst::Manual::Deployment(3pm)
All times are GMT -4. The time now is 04:07 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy