_oss_scale_table.html.md.erb

The following table provides recommended instance counts for a high-availability deployment. You can decrease the footprint of your deployment by specifying fewer instances and combining multiple components onto a single VM.

<table border="1" class="nice">
        <tr>
                <th><strong>Component</strong></th>
                <th><strong>Total Instances</strong></th>
                <th><strong>Notes</strong></th>
        </tr>
        <tr>
                <td>Diego Cell</td>
                <td>&ge; 2</td>
                <td>The optimal balance between CPU/memory sizing and instance count depends on the performance characteristics of the apps that run on Diego cells. Scaling vertically with larger Diego cells makes for larger points of failure, and more apps go down when a cell fails. On the other hand, scaling horizontally decreases the speed at which the system rebalances apps. Rebalancing 100 cells takes longer and demands more processing overhead than rebalancing 20 cells.</td>
        </tr>
        <tr>
                <td>Diego Brain</td>
                <td>&ge; 2</td>
                <td>One per AZ, or two if only one AZ.</td>
        </tr>
        <tr>
                <td>Diego BBS</td>
                <td>&ge; 2</td>
                <td>One per AZ, or two if only one AZ.</td>
        </tr>
        <tr>
                <td>PostgreSQL Server</td>
                <td>0 or 1</td>
                <td><code>0</code> if Postgres database is external.</td>
        </tr>
        <tr>
                <td>MySQL Proxy</td>
                <td>&ge; 2</td>
                <td></td>
        </tr>
        <tr>
                <td>NATS Server</td>
                <td>&ge; 2</td>
                <td>You might run a single NATS instance if you lack the resources to deploy two stable NATS servers. Components using NATS are resilient to message failures and the BOSH resurrector recovers the NATS VM quickly if it becomes non-responsive.</td>
        </tr>
        <tr>
                <td>Cloud Controller API</td>
                <td>&ge; 2</td>
                <td>Scale the Cloud Controller to accommodate the number of requests to the API and the number of apps in the system.</td>
        </tr>
        <tr>
                <td>Cloud Controller Worker</td>
                <td>&ge; 2</td>
                <td>Scale the Cloud Controller to accommodate the number of asynchronous requests to the API and background jobs.</td>
        </tr>
        <tr>
                <td>Router</td>
                <td>&ge; 2</td>
                <td>Scale the router to accommodate the number of incoming requests. Additional instances increase available bandwidth. In general, this load is much less than the load on host VMs.</td>
        </tr>
        <tr>
                <td>UAA</td>
                <td>&ge; 2</td>
                <td></td>
        </tr>
        <tr>
                <td>Doppler Server</td>
                <td>&ge; 2</td>
                <td>Deploying additional Doppler servers splits traffic across them. For high availability, use at least two per Availability Zone.</td>
        </tr>
        <tr>
                <td>Loggregator TC</td>
                <td>&ge; 2</td>
                <td>Deploying additional Loggregator Traffic Controllers allows you to direct traffic to them in a round-robin manner. For high availability, use at least two per Availability Zone.</td>
        </tr>
        <tr>
                <td>etcd</td>
                <td>&ge; 3</td>
                <td>Set this to an odd number equal to or one greater than the number of AZs you have, in order to maintain quorum. Distribute the instances evenly across the AZs, at least one instance per AZ.</td>
        </tr>
</table>