Cluster? Please!
Forum: DSL Ideas and Suggestions
Topic: Cluster? Please!
started by: Blfrg
Posted by Blfrg on May 13 2006,13:35
Rather than bumping an old post which received no replies, I decided to start my own thread.Let me start by saying this is my first post here. I am fairly new to linux but am picking it up quick with the help of some training from linuxcbt. I am quite ready to ditch all the overhead associated with Windows, and DSL has made me feel ways I should not describe in a public forum
With that said, let me quote the person who has already stated my concise desire for a feature which I feel other DSL lovers will appreciate as well:
| Quote |
| Rex: Posted: Aug. 06 2005,06:49 pxe booted clustering thin client. similar to clusterknoppix (too bad it's too huge and seem to be dead project?) it implement the way chaos do securing/encrypting openmosix clusters and allow diskless client to join the cluster. really hope somebody make the extension for dsl... |
Researching chaos (a 6mb cluster drone distro) it seems they worked on top of OpenMosix to enhance it's security. Thus it would be preferred over OpenMosix by itself. Details can be found at purehacking.com/chaos (hope it's ok to post that) or the original creators site midnightcode.org/projects/chaos/
This may be a bit of a stretch from DSL's primary functionality goals, but, short of suggesting another off-shoot [like DSL-N], I envision a DSL-CS (Cluster Server) type of addition or appendage to the current DSL.
I personally am hoping to set up a host network & would love to make DSL my ONLY distro! Throughout the front-end [possibly diskless] web servers, application servers & the back-end SANs, with some directive effort and these aspects in mind I am certain this can fruition into reality with DSL.
In closing I'd like to state, if DSL became the foundation for my dreams which I am currently in the process of pursuing, I would, without hesitation, do my part in helping support DSL through reasonable monetary contribution(s). Though, as a bit of an oxymoron, I couldn't employ my gratuitous offerings until after the fact
PS: I so deeply apologize for the novel. Some things just can't be efficiently summarized.
Please reply, even if you shoot down the suggestion. Thank you very much for your time.
Posted by kerry on May 13 2006,14:18
Well you can already do the server part. But why the need to cluster? Are you running several poorly spec'ed machines and trying to pool your resources? Perhaps you could run them all as servers set up in a network instead, and forward to the machines depending on use. Example: You could split the jobs up into different machines, say one that serves music, one that serves files, one that does images, one for mail,etc... It's just a matter of setting the first one up that connects to the internet to forward it back to the other machines via aliases(files aliase i92.168.0.1, music aliaes 192.168.0.2, etc...) and symlinks. Something like that, sounds like alot of work.
Posted by kerry on May 13 2006,14:41
Frontend ServersClusters of both types are usually equipped with Frontend Servers. Frontend Servers cannot access Account data directly - they always open connections to other (Backend) Servers to perform any operation with Account data.
Frontend servers accept TCP/IP connections from client computers (usually - from the Internet). In a pure Frontend-Backend configuration no Accounts are created on any Frontend Server, but nothing prohibits you from serving some Domains (with Accounts and mailing lists) directly on the Frontend servers.
When a client establishes a connection with one of the Frontend Servers and sends the authentication information (the Account name), the Frontend server detects on which Backend server the addressed Account can be opened, and establishes a connection with that Backend Server.
The Frontend Servers:
* handle all SSL/TLS encryption/decryption operations
* handle most of the SMTP relaying operations themselves
* virtually eliminate inter-server communications between Backend Servers, and (in Dynamic Clusters) provide second-level load balancing
* provide an additional layer of protection against Internet attacks and allow you to avoid exposing Backend Servers to the Internet
* smooth out the external traffic (soften peaks in the site load), and protect the Backend Servers from the Denial-of-Service attacks
If the Frontend Servers are directly exposed to the Internet, and the security of a Frontend Server operating system is compromised so that someone gets unauthorized access to that Server OS, the security of the site is not totally compromised. Frontend Servers do not keep any Account information (mailboxes, passwords) on their disks. The "cracker" would then have to go through the firewall and break the security of the Backend Server OS in order to get access to any Account information. Since the network between Frontend and Backend Servers can be disabled for all types of communications except the CommuniGate Pro inter-server communications, breaking the Backend Server OS is virtually impossible.
Both Static and Dynamic Clusters can work without dedicated Frontend Servers This is called a symmetric configuration, where each Cluster Server implements both Frontend and Backend functions.
In the example below, the domain1.dom and domain2.dom domain Accounts are distributed between three Static Cluster Servers, and each Server accepts incoming connections for these domains. If the Server SV1 receives a connection for the account kate@domain1.dom located on the Server SV2, the Server SV1 starts to operate as a Frontend Server, connecting to the Server SV2 as the Backend Server hosting the addressed Account.
At the same time, an external connection established with the server SV2 can request access to the ada@domain1.dom account located on the Server SV1. The Server SV2 acting as a Frontend Server will open a connection to the Server SV1 and will use it as the Backend Server hosting the addressed account.
In a symmetric configuration, the number of inter-server connections can be equal to the number of external (user) access-type (POP, IMAP, HTTP) connections. For a symmetric Static Cluster, the average number of inter-server connections is M*(N-1)/N, where M is the number of external (user) connections, and the N is the number of Servers in the Static Cluster. For a symmetric Dynamic Cluster, the average number of inter-Server connections is M*(N-1)/N * A/T, where T is the total number of Accounts in Shared Domains, and A is the average number of Accounts opened on each Server. For large ISP-type and portal-type sites, the A/T ratio is small (usually - not more than 1:100).
In a pure Frontend-Backend configuration, the number of inter-server connections is usually the same as the number of external (user) connections: for each external connection, a Frontend Server opens a connection to a Backend Server. A small number of inter-server connections can be opened between Backend Servers, too.
Posted by kerry on May 13 2006,15:01
I was looking into this sometime back. My idea was to run dsl in ram with the hd formatted as one large swap for storing the info. I was thinking this would provide a great deal of security as there would be no actuall file partions for anyone to hack. But as they say info is info no matter how it's stored. 