
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div><div>I'm working on some services that require the ability to place VMs onto the same or separate racks, and I wanted to start a discussion to see what the community thinks the best way of achieving this with Nova might be.</div><div><br></div><div>Quick overview:</div><div><br></div><div>Various clustered datastores require related data to be placed in close proximity (such as on the same rack) for optimum read latency across contiguous/partitioned datasets. Additionally, clustered datastores may require that replicas be placed in particular locations, such as on the same rack to minimize network saturation or on separate racks to enhance fault tolerance. An example of this is Hadoop's common policy of placing two replicas onto one rack and another onto a separate rack. For datastores that use ephemeral storage, the ability to control the rack locality of Nova VMs is crucial for meeting these needs. Breaking this down we come up with the following potential requirements:</div><div><br></div><div>1. Nova should allow a VM to be booted onto the same rack as existing VMs (rack affinity).</div><div>2. Nova should allow a VM to be booted onto a different rack from existing VMs (rack anti-affinity).</div><div>3. Nova should allow authorized services to learn which rack a VM resides on.</div><div><br></div><div>Currently, host aggregates are the best way to approximate a solution for requirements 1 and 2. One could create host aggregates to represent the physical racks in a datacenter and boot VMs into those racks as necessary, but there are some challenges with this approach including the management of different flavors to correspond to host aggregates, the need to determine the placement of existing VMs, and the general problem of maintaining the host aggregate information as hosts come and go. Simply booting VMs with server-group style rack affinity and anti-affinity is not a direct process. Requirement 3 is a move towards allowing authorized in cloud services to learn about their location relative to other cloud resources such as Swift, so that they might place compute and data in close proximity.</div><div><br></div><div>I'm interested to gather input on how we might approach this problem and what the best path forward for implementing a solution might be. Please share your ideas and input. It's also worth noting that a similar/related need exists for Swift which I'm addressing in a separate message.</div><div><br></div><div>Cheers,</div><div>Jonathan</div></div></body></html>