W-16132496-CH2-Networking-Guide-LDS #227
There are no files selected for viewing
|
There was a problem hiding this comment.
|
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,196 @@ | ||
| = CloudHub 2.0 Networking Architecture | ||
|
|
||
| CloudHub 2.0 is MuleSoft's fully managed, containerized integration platform as a service (iPaaS) where you can deploy APIs and integrations as lightweight containers in the cloud so they are maintainable, secure, and scalable. | ||
|
|
||
| This document provides relevant information regarding the configuration and administration of CloudHub 2.0 networks, network interfaces, and network services. For information about different deployment scenarios, see xref:runtime-manager::deployment-strategies.adoc[]. | ||
|
|
||
| The basic components of CloudHub 2.0 networking architecture are HTTP Load Balancer, Mule replica DNS records, Private Spaces, and Regional Services. | ||
|
|
||
| * <<HTTP Load Balancer>> | ||
| * <<DNS Records>> | ||
| * <<Private Spaces Configurations>> | ||
| * <<Regional Services>> | ||
|
|
||
| image::ch2-networking-architecture-diagram.png[Basic Components of CloudHub 2.0 Networking Architecture] | ||
|
|
||
| == HTTP Load Balancer | ||
|
|
||
| CloudHub 2.0 provides a load balancing service for all integrations. You can use a default endpoint or provision a custom endpoint with your own certificate. | ||
|
|
||
| When you deploy an application to two or more replicas, CloudHub 2.0 provides an HTTP load balancing service that automatically distributes HTTP requests among your assigned replicas. | ||
|
|
||
| The CloudHub 2.0 load balancing service performs a round-robin load distribution across application replicas, which provides horizontal scalability. The load balancing service also provides transparent switchover when an application is upgraded. See xref:ch2-update-apps.adoc[]. | ||
|
|
||
| Each application deployed to CloudHub 2.0 has both default public and internal DNS records that refer to the load balancer: `<app>.<space-shard>.region.cloudhub.io.` and `<app>.internal-<space-shard>.region.cloudhub.io.`. | ||
|
There was a problem hiding this comment. add brackets to region as well? like ...cloudhub.io? There was a problem hiding this comment. Ye the region should be in brackets like There was a problem hiding this comment. Do we want to elaborate on what |
||
|
|
||
| The CloudHub 2.0 load balancing service accepts public traffic on the standard HTTPS port: `443`. You can also choose to accept HTTP traffic on the standard HTTP port: `80`. | ||
|
There was a problem hiding this comment. I believe this comment is exclusive to Private Space. For Shared Space, customer cannot choose to accept port 80. There was a problem hiding this comment. Add clarification. |
||
|
|
||
| === Mule Application Ports | ||
|
|
||
| Applications must listen on host `0.0.0.0` and port via the reserved property `${http.port}`. You can dynamically allocate the value of this property, but you can't hard-code it. | ||
|
There was a problem hiding this comment. What do we mean by From my understanding, there are 3 options (2 options when using the HTTP Load Balancer). If customer uses any other port, the request via HTTP Load Balancer will fail. There was a problem hiding this comment. MuleSof allocates the value of this property, (do not mention hard-coding) |
||
|
|
||
| The load balancing service forwards traffic to deployed applications. | ||
|
|
||
| === Upstream HTTPS Traffic | ||
|
|
||
| By default, the load balancing service forwards traffic deployed application over HTTP. To use HTTPS: | ||
|
There was a problem hiding this comment. sentence seems incomplete - traffic "to the" deployed app? There was a problem hiding this comment. ye that sentence needs to be reworded. |
||
|
|
||
| * Enable the *Last-Mile Security* setting in the *Ingress* tab of the xref:ch2-deploy-private-space.adoc#configure-endpoint-path[deployment settings]. | ||
| * Configure the application to listen on HTTPS by providing a certificate in the xref:ps-config-domains.adoc[TLS context] of your private space. | ||
|
There was a problem hiding this comment. I think this statement is wrong regarding the hyperlink we have for TLS context. The hyperlink points to the TLS context configuration for external client to Private Space. Whereas this sentence is talking about last-mile security between, which is something customer needs to configure themselves within the mule app. There was a problem hiding this comment. We'll get rid of the link. |
||
|
|
||
| The following example shows a Mule application configuration that exposes an HTTPS endpoint: | ||
|
|
||
| [source,console,linenums] | ||
| ---- | ||
| <http:listener-config name="HTTP_Listener_Configuration" protocol="HTTPS" host="0.0.0.0" port="${http.port}" doc:name="HTTP Listener Configuration" > | ||
| <tls:context name="TLS_Context_Custom_Keystore" doc:name="TLS Context"> | ||
| <tls:key-store type="jks" path="server.jks" keyPassword="" password="" alias="" /> | ||
| </tls:context> | ||
| </http:listener-config> | ||
| ---- | ||
|
|
||
| === Load Balancer Connections | ||
|
|
||
| For each request a client makes through the CloudHub 2.0 load balancer `(<app>.<space-id>.region.cloudhub.io)`, the load balancer maintains two connections: one connection between the client and the load balancer, and another connection between the load balancer and the application. For each connection, the load balancer manages a default idle timeout of 300 seconds that is triggered when no data is sent over either connection. If no data is sent or received during this duration, the load balancer closes both connections. | ||
|
There was a problem hiding this comment. Here we say |
||
|
|
||
| For connections that take longer than 300 seconds to process from either side, handle the processing asynchronously. You can customize the idle timeout value in the *Advanced* tab of your xref:ps-config-advanced.adoc#configure-http-requests-and-read-response-timeout[private space settings] in Runtime Manager, or via the Mule application xref:mule-runtime::global-settings-configuration.adoc[global configurations] of the xref:mule-runtime::about-mule-configuration.adoc[Mule configuration file]. | ||
luanamulesoft marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| == DNS Records | ||
|
|
||
| The following DNS records are exposed for your CloudHub 2.0 applications: | ||
|
|
||
| [cols="2*a"] | ||
| |=== | ||
| |`*.<space-id>.<region>.cloudhub.io`|Applications running inside a private space. | ||
| |`<space-id>.<region>.cloudhub.io`|Record pointing to the load balancer. Use this record as the target of a custom domain CNAME. | ||
| |`*.internal-<space-id>.<region>.cloudhub.io`|Applications running inside a private space. The IP addresses for this DNS record are accessible only within your xref:ch2-private-space-about.adoc[private spaces]. They cannot be accessed within xref:ch2-shared-space-about.adoc[shared spaces]. | ||
| |`internal-<space-id>.<region>.cloudhub.io`|Internal load balancer. Use this record as the target of a custom domain CNAME. The IP addresses for this DNS record are accessible only within your private spaces. They cannot be accessed within shared spaces. | ||
|
There was a problem hiding this comment. The "Use this record as the target of a custom domain CNAME" comment for the last entry (internal load balancer) is wrong. We currently don't support custom domain CNAME for the internal LB. Is that correct? There was a problem hiding this comment. We don't support a vanity domain for private endpoints. But we can still put the internal domain as a target, right? There was a problem hiding this comment. SME confirmed that it is correct as it is now. There was a problem hiding this comment. Are we planning to have vanity domains for private endpoints released, before we publish this doc? For the public endpoint scenario:
For the private endpoint scenario:
Based on my above examples, I don't understand how that statement is valid when we don't support vanity domains for the private endpoint. |
||
| |=== | ||
|
|
||
|
|
||
| == Private Spaces Configurations | ||
|
|
||
| The following configurations apply to private spaces only. | ||
|
|
||
| === Application-to-Application Communication | ||
|
|
||
| An application communicates with another application via: | ||
|
|
||
| * The default public DNS name: `app.sxjsip.aus-s1.cloudhub.io` | ||
| * The default internal DNS name (in private spaces only): `app.internal-sxjsip.aus-s1.cloudhub.io` | ||
| * The custom domain name (if configured): `acme.example.com` | ||
| * The cluster local DNS: `app` or `app.envid.svc.cluster.local` | ||
|
There was a problem hiding this comment. Should we include the port number here too "app.envid.svc.cluster.local"? There was a problem hiding this comment. Change to: app.envid.svc.cluster.local:8081 |
||
|
|
||
| If you use the internal DNS name, traffic remains within the private space network. You can delete or omit the externally exposed endpoint when deploying an application to a private space. In that case, you can use the application's internal endpoint for internal traffic. | ||
|
|
||
| If you use the cluster local endpoint, the traffic doesn't leave the cluster. However, the cluster local endpoint isn't highly available. During some cluster operations such as disaster recovery, the endpoint can be unreachable. The cluster local endpoint allows traffic within the same environment only. | ||
|
There was a problem hiding this comment. What are we referring to when we say 'cluster' here? Can we replace with 'private space' - to avoid exposing details that private space == cluster There was a problem hiding this comment. "However, the cluster local endpoint isn’t highly available. During some cluster operations such as disaster recovery, the endpoint can be unreachable." How is this different from using the internal DNS name? Since in this statement we are saying/suggesting that using the internal DNS name is better than using the cluster local endpoint. We will surely get customers asking what are the specific differences so they can make their decision. My personal understanding was using the cluster local endpoint is better (less hops), and customer just lose out on a common log aggregation point (the ingress LB) for audit purposes. How is using the cluster local endpoint less highly available compared to using the internal DNS name? Isn't using the internal DNS name the same, because the ingress will be forwarding traffic to the cluster local endpoint anyway. |
||
|
|
||
| === Custom Domain Name | ||
|
|
||
| You can apply custom certificates to your private space. CloudHub 2.0 parses the CN and SAN list from the certificate and makes those domains available when deploying applications. | ||
|
|
||
| Configure either in the public or the internal DNS record to CNAME. For example: | ||
|
There was a problem hiding this comment. I thought we don't support custom domain name for internal endpoint/DNS record (at least not yet?). There was a problem hiding this comment. SME confirmed it is correct as it is There was a problem hiding this comment. we don't support private custom domain. but we can still do the CNAME to the internal DNS record, right? |
||
|
|
||
| ---- | ||
| *.example.com => sxjsip.aus-s1.cloudhub.io | ||
| *.example.com => internal-sxjsip.aus-s1.cloudhub.io | ||
| ---- | ||
|
|
||
| === IP Ranges | ||
|
|
||
| Inbound traffic entering a private space originates from an IP address listed under the *Inbound Static IPs* field of the private network configuration. HTTP connections can inspect the `X-Forwarded-For` header to discover the original client IP address. | ||
|
There was a problem hiding this comment. I think this sentence is wrong. The inbound static IPs are what a client would target to reach their private space. Inbound traffic entering a private space does NOT originate from the inbound static IP. The public DNS target resolves to these inbound static IPs. There was a problem hiding this comment. We'll remove the whole paragraph for the time being |
||
|
|
||
| Traffic egressing to the internet originates from an IP address listed under the *Outbound Static IPs* field of the private network configuration. The public DNS target and the private DNS target IPs don't change during the lifetime of the private space. | ||
|
There was a problem hiding this comment. I think this sentence is incorrectly associating the Outbound Static IPs with the public and private DNS targets. The public DNS target is associated with the inbound static IPs, not outbound static IPs. Also regarding the changing of IPs during the lifetime of the private space. I know the public IP won't change, but do we have confirmation that the private IP (i.e. the IPs belonging to the NLBs) won't change as well? There was a problem hiding this comment. Separate paragraphs to fix it |
||
|
|
||
| Traffic egressing to a VPN or transit gateway originates from the private space CIDR block. | ||
|
|
||
| image::ch2-networking-ip-ranges.png[Inbound and outbound IPs listed in the UI] | ||
|
|
||
| Private spaces also leverage several secondary CIDR for internal usage. | ||
|
|
||
| If you use BGP routing protocols, you may see the following additional CIDR blocks being published to your gateway: | ||
|
|
||
| ---- | ||
| 100.64.0.0/16 | ||
| 100.66.0.0/16 | ||
| 100.67.0.0/16 | ||
| 100.68.0.0/16 | ||
| ---- | ||
|
|
||
| Because of this, `100.64.0.0/10` is xref:ps-gather-setup-info.adoc#unusable-cidr[not a supported range] for private spaces. | ||
|
|
||
| You can filter these prefixes from the route map. For more informationm see https://help.mulesoft.com/s/article/Received-Extra-BGP-routes-from-CloudHub-2-0-VPN[Received Extra BGP routes from CloudHub 2.0 VPN]. | ||
|
|
||
| You can also indicate a reserved range for your on-prem network when creating your private space. CloudHub 2.0 doesn't use reserved ranges indicated by customers. For more information, see xref:ps-gather-setup-info.adoc#reserved-cidr[Reserved Corporate CIDR]. | ||
|
|
||
| === Connections | ||
|
|
||
| Private spaces support two types of connections: Virtual Private Network (VPN) and Transit Gateway (TGW). | ||
luanamulesoft marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Each Anypoint VPN connection consists of two tunnels that enable you to connect to a single public IP address at a remote location. VPNs are high available if you configure both tunnels on your endpoint. | ||
|
|
||
|
|
||
| Additionally, CloudHub 2.0 enables you to define redundant VPN connections for additional resiliency. As a managed VPN service, the underlying VPN service is frequently upgraded. Routine maintenance can briefly disable one of the two tunnels of your VPN connection. Your VPN connection automatically fails over to the second tunnel during this time, so access is not interrupted. For this reason, you must configure both tunnels on your endpoint. For more information, see https://help.mulesoft.com/s/article/Tunnel-Switch-in-an-Anypoint-Dynamic-BGP-VPN-Update[Tunnel Switch in an Anypoint Dynamic (BGP) VPN Update]. | ||
luanamulesoft marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| By design, TGW connections are already highly available. Don't create redundant TGW connections. For more information, see xref:ps-tgw-about.adoc[]. | ||
luanamulesoft marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ==== Connections between CloudHub and CloudHub 2.0 | ||
|
|
||
| You can use a xref:ps-create-configure-tgw.adoc[TGW attachment] to connect a dedicated VPC in CloudHub to a CloudHub 2.0 private space. You must apply the attachments independently in CloudHub and CloudHub 2.0. | ||
luanamulesoft marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
|
|
||
| === Firewall Rules and Port Access | ||
|
|
||
| HTTP Ingress:: | ||
|
|
||
| By default, ports `443` and `80` are exposed for all external inbound traffic. You can remove or change these ports to restrict inbound traffic. | ||
|
|
||
|
|
||
| Non-HTTP Ingress:: | ||
|
|
||
| By default, no non-http ports are open. You can open a fixed list of TCP ports (30500-32500) to allow non-http traffic to flow to your Mule applications. Those ports are only reachable from within the private space or originated from a VPN or a TGW. For more information about how to allow TCP traffic for your private space, see xref:ch2-deploy-api.adoc[]. | ||
|
|
||
|
|
||
| Egress:: | ||
|
|
||
| By default, applications can make outbound connections to any destination and ports. You can change this behavior to restrict egress traffic. | ||
|
There was a problem hiding this comment. Should we drop the "s" here in "to any destination and ports."? |
||
| + | ||
| You can remove all ingress and egress rules from and to the internet. In this case, the cluster still functions normally because of the following control measures: | ||
|
There was a problem hiding this comment. Again - should we say 'private space' or 'space' instead of cluster? There was a problem hiding this comment. "You can remove all ingress and egress rules from and to the internet. In this case, the cluster still functions normally because of the following control measures:" I think this statement is incorrect. Especially regarding the below bullet point "You can apply egress rules at the application level.". If customer removes all PS-level egress rules and adds the app-level egress rules, traffic will still fail. When using app-level egress rules, you need to allow the broader traffic at the PS-level and the more specific traffic at the app-level. It is 2 layers of security rules that the traffic goes through. It needs to be allowed by both the app-level and PS-level FW rules. |
||
| + | ||
| * Anypoint Monitoring ingestion traffic firewall rules are implicitly added to all Mule applications' firewall rules. | ||
| * Essential AWS services traffic flows are always allowed from Mule applications. | ||
| * You can apply egress rules at the application level. Fore more information, see xref:ps-config-app-level-egress.adoc[]. | ||
|
|
||
| * You can remove default route to IGW. However, for the egress firewall rules to work, the destination IPs must be routable. | ||
|
There was a problem hiding this comment. In the Anypoint Platform UI we have "Internet Gateway". I think we should use that here instead of the acronym IGW. Unless we define it. |
||
|
|
||
|
|
||
| == Regional Services | ||
|
|
||
| The DNS record and the load balancer for your integration may change depending on what region you deploy your applications in. The following table summarizes what DNS records are available for your applications in each region: | ||
|
|
||
| Anypoint Platform for the U.S. control plane covers the following regions: | ||
luanamulesoft marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| [%header,cols="2*a"] | ||
| |=== | ||
| | Regions in U.S. Control Plane | DNS Record | ||
| | US East (N. Virginia) | `<app>.<space-id>.usa-e1.cloudhub.io` | ||
| | US East (Ohio) | `<app>.<space-id>.usa-e2.cloudhub.io` | ||
| | US West (N. California) | `<app>.<space-id>.usa-w1.cloudhub.io` | ||
| | US West (Oregon) | `<app>.<space-id>.usa-w2.cloudhub.io` | ||
| | Canada (Central) | `<app>.<space-id>.can-c1.cloudhub.io` | ||
| | South America (Sao Paulo) | `<app>.<space-id>.bra-s1.cloudhub.io` | ||
| | Asia Pacific (Singapore) | `<app>.<space-id>.sgp-s1.cloudhub.io` | ||
| | Asia Pacific (Sydney) | `<app>.<space-id>.aus-s1.cloudhub.io` | ||
| | Asia Pacific (Tokyo) | `<app>.<space-id>.jpn-e1.cloudhub.io` | ||
| | EU (Ireland) | `<app>.<space-id>.irl-e1.cloudhub.io` | ||
| | EU (Frankfurt) | `<app>.<space-id>.deu-c1.cloudhub.io` | ||
| | EU (London) | `<app>.<space-id>.gbr-e1.cloudhub.io` | ||
| |=== | ||
|
|
||
|
|
||
| Anypoint Platform for the EU control plane covers the following regions: | ||
|
|
||
| [%header,cols="2*a"] | ||
| |=== | ||
| | Regions in EU Control Plane | DNS Record | ||
| | EU (Ireland) | `<app>.<space-id>.irl-e1.eu1.cloudhub.io` | ||
| | EU (Frankfurt) | `<app>.<space-id>.deu-c1.eu1.cloudhub.io` | ||
| |=== | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should show where TGW attachments and / VPN sits as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also need a diagram for shared spaces.