openstack team mailing list archive

[John Dickinson <me@xxxxxx>]

From the Swift perspective, there isn't any reason other services can't be run on the Swift boxes. I'd check for a few things, though.

1) Make sure dependencies aren't in conflict. Thanks to the work of the CI team, this should be mostly sane.

2) Obviously, monitor your systems and don't overload something. Some parts of Swift will use CPU (eg the proxy servers) and other will use IOPS (eg container and object servers). Try to balance the other things you run to complement each other.

3) If you have enough hardware to have separate proxy and storage nodes, Swift assumes that your storage nodes will be on a private network (ie Swift doesn't provide any additional security to the messages within the cluster). Although there are some proposed ideas about making this better, I wouldn't put other public services on boxes running the backend Swift storage processes, at least without some additional limitations on what can connect to the Swift ports.

4) Make sure the ports you are running the services on don't conflict. All of the ports used by Swift are configurable.

So while it's not a "terrible, terrible idea", I certainly wouldn't call it "best practice". You can make it work, just pay attention to what you're doing.

--John




On Nov 4, 2012, at 5:18 PM, Tom Fifield <fifieldt@xxxxxxxxxxxxxx> wrote:

> Hi,
> 
> This came in as a doc bug, but I thought I'd throw it to the list:
> 
> https://bugs.launchpad.net/openstack-manuals/+bug/988053
> 
> "I think it would be worthwhile to talk about what services can be
> co-located on the same servers as Swift. For example "Can I run Keystone
> in combination with Swift Proxy and Swift Storage?""
> 
> example other potential combo that "might not break": glance / swift proxy
> 
> I think this is most relevant to small-scale deployments, where there
> isn't quite enough hardware to go around, rather than anywhere
> approaching best practice ;)
> 
> 
> Realistically expecting "this is a terrible, terrible idea" replies to
> this, but perhaps reasons, and the odd outside-the-box idea will be
> presented ...
> 
> 
> Regards,
> 
> Tom
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

Attachment: smime.p7s
Description: S/MIME cryptographic signature