_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>
<thead>
        <tr>
                <th><strong>Component</strong></th>
                <th><strong>Total Instances</strong></th>
                <th><strong>Notes</strong></th>
        </tr>
</thead>
<tbody>
        <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. NATS includes metrics as well as route registration and deregistration messages. <%= vars.recommended_by %> recommends scaling NATS VMs to 2 or more CPU.</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 (AZ).</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 AZ.</td>
        </tr>
        <tr>
                <td>Log Cache</td>
                <td>&ge; 1</td>
                <td>Deploying additional Log Cache instances increases the total storage, sharding data by app ID. If app logs and metrics are sharded to an unavailable instance, they are unavailable when the designated instance is unavailable regardless of the number of instances or AZs.</td>
        </tr>
</tbody>
</table>