Machines (Servers) are headless node types in the SD-WAN Client solution.
A headless node is a device that needs to participate in the fabric but is not tied to a human user that can provide authentication credentials when prompted. The ATM and the Machines (Servers) will be created here in this use-case example. Be sure to assign the server to its appropriate group created in the previous section of the guide.
Pay close attention to dc1-banking-app. This server has two SD-WAN Client IP addresses. Two individual servers hosting the banking application were authenticated to the fabric using the same access token. The result is that the Orchestrator and fabric view this server node as a single object. Most likely, the application the ATMs are accessing is known by its fully qualified domain name (FQDN) and not the overlay IP address. This allows for applying the same FQDN to multiple servers.
The ability to reuse a token to add multiple machines provides the benefit of not having to provision a new node in the event of a device failure. Simply reapply the token to the functioning machine and remove the failed machine from service by using the trashcan icon to the right.
Please note that if your organization does not prefer to have the software running directly on the application servers, an alternative option would be to deploy a Client Connector in front of the destination IP or FQDN for the application. For more detail on how to do this, refer to the OT section of the design guide that highlights this deployment model.
The second machine, dc1-ms-config-mgmt-1, follows a slightly different design pattern. Instead of adding multiple servers to the node, the Orchestrator has a one-to-one mapping. The logic is that this machine is used to manage endpoints, and since it sends traffic to endpoints and does not receive traffic from them, it does not need to take advantage of a shared FQDN, load-balancing, or resiliency. Those will be taken care of by the existing machine and network design.
Finally, with the ATM, it is best to maintain a one-to-one relationship between what is created in the Orchestrator and what exists on location. The reasoning here is that you can quickly identify and remove individual ATMs from service. However, if you took advantage of the functionality described for the dc1-banking-app, you would not have a precise mapping of which SD-WAN Client IP belonged to the target ATM you wished to remove from service.
To further expand on FQDN in the dc1-banking-app server configuration, consider that the application the server hosts is known to the ATMs as "atm.app.internal". Instead of updating your internal DNS servers with the Client IPs assigned to the servers, you can simply modify a field in the machine modal in the Orchestrator.
