Request for Additional Detail in Swift Documentation - keystone and swift proxy colo
Bug #988053 reported by
Richard Raseley
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openstack-manuals |
Fix Released
|
Low
|
Tom Fifield |
Bug Description
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?"
summary: |
- Request for Additional Detail in Swift Documentation + Request for Additional Detail in Swift Documentation - keystone and + swift proxy colo |
Changed in openstack-manuals: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
tags: | removed: documentation |
Changed in openstack-manuals: | |
importance: | Medium → Low |
Changed in openstack-manuals: | |
status: | Triaged → In Progress |
assignee: | nobody → Tom Fifield (fifieldt) |
To post a comment you must log in.
A fantastic response from John Dickinson himself:
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.