Skip to content

Commit b804fd0

Browse files
committed
add network overview
1 parent 40c429b commit b804fd0

File tree

3 files changed

+59
-5
lines changed

3 files changed

+59
-5
lines changed
Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
---
2+
title: "Networking: Azure Modeling and Simulation Workbench"
3+
description: About networking architecture in the Azure Modeling and Simulation Workbench.
4+
author: yousefi-msft
5+
ms.author: yousefi
6+
ms.service: modeling-simulation-workbench
7+
ms.topic: concept-article
8+
ms.date: 10/13/2024
9+
10+
#CustomerIntent: As an administrator, I want to understand the networking architecture and capabilities in Azure Modeling and Simulation Workbench.
11+
---
12+
13+
# Networking overview
14+
15+
The Azure Modeling and Simulation Workbench is a managed, cloud-based platform-as-a-service (PaaS) with an isolated network infrastructure. [Chambers](./concept-chamber.md) are designed for confidentiality and each is a self-contained, private work environment. No connections to the internet, to other chambers are possible. The network architecture allows only remote desktop connection to chamber virtual machines (VM). No file mounts, SSH, or custom connections are possible from outside a chamber.
16+
17+
This article provides an overview of the Modeling and Simulation Workbench network architecture and provides references to guides for managing those resources.
18+
19+
## Chamber networking
20+
21+
[Chambers](./concept-chamber.md) are isolated environments where users in the same enterprise or organization can freely collaborate. Every virtual machine in the same chamber is deployed to the same subnet as and can directly communicate to other VMs in the same chamber. Chamber VMs can't communicate with the internet or other chambers or any on-premises infrastructure. Chamber-to-chamber communication is only possible using [shared storage](./concept-storage.md#workbench-tier-shared-storage). Virtual machines (VM) can only be reached using a remote desktop connection by users who provisioned for the chamber.
22+
23+
### Desktop service
24+
25+
A remote desktop client is required to communicate with chamber VMs. Only the approved solution is able to make a connection to chamber VMs and must be started from the connector. Refer to the [Quickstart: Connect to desktop](quickstart-connect-desktop.md) article to learn how to connect to a VM. VMs aren't exposed outside of a chamber and therefore can't be accessed via SSH. You can SSH to another VM once in the desktop environment.
26+
27+
### Chamber license service
28+
29+
Every chamber has its own [license service](./concept-license-service.md). License servers for the major Electronic Design Automation (EDA) vendors are preinstalled and configured in each chamber. The license servers are only accessible to VMs in the same chamber and can't be accessed or integrated with other license servers in other chambers or on-premises infrastructure.
30+
31+
### Red Hat package repository
32+
33+
Azure maintains a private mirror of the official Red Hat Update Infrastructure (RHUI). Chamber VMs can access the Azure RHUI using the Red Hat's `yum` and `dnf` package managers.
34+
35+
### Firewalls
36+
37+
The Modeling and Simulation Workbench offers the standard Azure image of Red Hat Enterprise Linux (RHEL) 8.8, with only a few modifications. The `firewalld` daemon, shipped and enabled by default on all RHEL 8.8 images, is also enabled in Modeling and Simulation Workbench chamber VMs.
38+
39+
> [!IMPORTANT]
40+
> The `firewalld` service might block communications for applications and services not installed via a Red Hat package or package manager. Refer to the application's documentation and the guide to [configure firewalls](how-to-guide-configure-firewall-red-hat.md) on how to manage firewall rules. Modifying firewalls on individual VMs won't enable access to VMs located in the other chambers or on-premises infrastructure.
41+
42+
## Connectors
43+
44+
[Connectors](concept-connector.md) are resources associated with chambers and configure networking access to a chamber from outside a workbench. Connectors are created either as public IP or private network connector. [Public IP](./how-to-guide-public-network.md) connectors are accessible from the internet and access is controlled with an allowlist. [Private network](./how-to-guide-private-network.md) connectors are deployed to a private virtual network in your subscription.
45+
46+
## Storage and data pipelines
47+
48+
There are several types and tiers of [storage](./concept-storage.md) in the Modeling and Simulation Workbench. Storage local to a VM, [chamber storage](./how-to-guide-manage-chamber-storage.md), and [shared storage](./how-to-guide-manage-shared-storage.md) are accessible outside of a chamber. Storage volumes can't be mounted or accessed from the internet or on-premises infrastructure.
49+
50+
The [data pipeline](./concept-data-pipeline.md) is the only means of [exporting](./how-to-guide-download-data.md) or [importing](./how-to-guide-upload-data.md) into a workbench.
51+
52+
## Related content
53+
54+
- [Write concepts](article-concept.md)

articles/modeling-simulation-workbench/how-to-guide-private-network.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -72,8 +72,8 @@ Modeling and Simulation Workbench creates three private domain name service (DNS
7272
| Service | Public cloud DNS zone | Azure Gov cloud DNS Zone |
7373
|:--------------------------------------|:----------------------------------|-----------------------------------------|
7474
| Connector desktop dashboard and nodes | mswb.azure.com | mswb.azure.us |
75-
| Data in pipeline endpoint | privateLink.blob.core.windows.net | privatelink.blob.core.usgovcloudapi.net |
76-
| Data out pipeline endpoint | privateLink.file.core.windows.net | privatelink.blob.core.usgovcloudapi.net |
75+
| Data in pipeline endpoint | privatelink.blob.core.windows.net | privatelink.blob.core.usgovcloudapi.net |
76+
| Data out pipeline endpoint | privatelink.file.core.windows.net | privatelink.blob.core.usgovcloudapi.net |
7777

7878
## Ports and IP addresses
7979

@@ -88,7 +88,7 @@ The Azure Modeling and Simulation Workbench require certain ports to be accessib
8888

8989
### IP addresses
9090

91-
The private network connector doesn't deploy any public IP network interfaces. You create your own gateway interface if connecting directly from the internet. Your choice of which region you deploy your gateway to determines from which pool of Azure public IP addresses your gateway is chosen. Azure IP addresses are taken from Azure's IP ranges for the location in which the Workbench was deployed. A list of all Azure IP addresses and Service tags is available at [Azure IP Ranges and Service Tags – Public Cloud](https://www.microsoft.com/download/details.aspx?id=56519&msockid=1b155eb894cc6c3600a84ac5959a6d3f).
91+
The private network connector doesn't deploy any public IP network interfaces or gateways. You must create your own gateway interface if connecting directly from the internet or peer the virtual network to another. The region you deploy your gateway interface to determines from which pool of Azure public IP addresses your gateway IP is chosen. Azure IP addresses are taken from Azure's IP ranges for the location in which the Workbench was deployed. A list of all Azure IP addresses and Service tags is available at [Azure IP Ranges and Service Tags – Public Cloud](https://www.microsoft.com/download/details.aspx?id=56519&msockid=1b155eb894cc6c3600a84ac5959a6d3f).
9292

9393
The private IP addresses for the private networking connector are implemented as private network interface connections (NIC) on the virtual network's subnet you specified during initial deployment.
9494

articles/modeling-simulation-workbench/how-to-guide-public-network.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -132,15 +132,15 @@ The Azure Modeling and Simulation Workbench require certain ports to be accessib
132132
For the Public IP connector, Azure IP addresses are taken from Azure's IP ranges for the location in which the Workbench was deployed. A list of all Azure IP addresses and Service tags is available at [Azure IP Ranges and Service Tags – Public Cloud](https://www.microsoft.com/download/details.aspx?id=56519&msockid=1b155eb894cc6c3600a84ac5959a6d3f). It's not possible to list all Workbench IP addresses when the public IP connector is implemented.
133133

134134
> [!CAUTION]
135-
> The pool of IP addresses can increase not only by adding VMs, but users as well. Connection nodes are scaled up or down when users are added to or removed from the chamber. Any discovery of endpoint IP addresses will be incomplete if the userbase changes.
135+
> The pool of IP addresses can increase not only by adding VMs, but adding users as well. Connection nodes are scaled up or down when users are added to or removed from the chamber. Any discovery of endpoint IP addresses will be incomplete if the userbase changes.
136136
137137
For more control over destination IP addresses and to minimize changes to corporate firewalls, a [private networking connector](how-to-guide-private-network.md) is recommended. A VPN Gateway and the private networking connector allow greater control of the ingress, egress, and name server operations of the workbench. The access point to the workbench is the single gateway IP address or a peered virtual network.
138138

139139
Network interfaces aren't deployed into the user's subscription and aren't accessible to users. Users can't associate network security groups (NSG) nor can they apply other Azure networking services such as firewalls to these interfaces.
140140

141141
## DNS zones
142142

143-
The public connector option uses Azure public DNS servers and creates a CNAME entry for each of your named endpoints. The subdomain zone and its corresponding service are listed in the following table. There are three zones for public cloud and two for Azure Government (US) cloud.
143+
The public connector option uses Azure public DNS servers and creates a CNAME entry for each of your named endpoints in the corresponding zone. The subdomain zone and its corresponding service are listed in the following table. There are three zones for public cloud and two for Azure Government (US) cloud.
144144

145145
| Service | Public cloud DNS zone | Azure Gov cloud DNS Zone |
146146
|:--------------------------------------|:----------------------|-----------------------------|

0 commit comments

Comments
 (0)