Skip to content

Commit cf066c9

Browse files
okrauseokrause
authored
Adds two new blueprints for all-in-cloud and hybrid-cloud EDA workloads (#4931)
1 parent 22a079a commit cf066c9

File tree

7 files changed

+742
-2
lines changed

7 files changed

+742
-2
lines changed

‎community/examples/eda/README.md‎

Lines changed: 250 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,250 @@
1+
# Electronic Design Automation (EDA) Reference Architecture
2+
3+
The Electronic Design Automation (EDA) blueprints in
4+
this folder capture a reference architecture where the right cloud components
5+
are assembled to optimally cater to the requirements of EDA workloads.
6+
7+
For file IO, Google Cloud NetApp Volumes NFS storage services are available.
8+
It scales from small to high capacity and high performance and provides fan-out
9+
caching of on-premises ONTAP systems into Google Cloud to enable hybrid cloud
10+
architecture. The scheduling of the workloads is done by a workload
11+
manager.
12+
13+
## Architecture
14+
The EDA blueprints are intended to be a starting point for more tailored
15+
explorations of EDA.
16+
17+
This blueprint features a general setup suited for EDA applications on
18+
Google Cloud including:
19+
20+
- Google Compute Engine partitions
21+
- Google Cloud NetApp Volumes NFS-based shared storage
22+
- Slurm workload scheduler
23+
24+
Two example blueprints are provided.
25+
26+
### Blueprint [eda-all-on-cloud](eda-all-on-cloud.yaml)
27+
28+
This blueprint assumes that all compute and data resides in the cloud.
29+
30+
In the base deployment group (see [deployment stages](#deployment_stages)) it provisions a new network and multiple volumes to store your data. Adjust the volume sizes to suit your requirements before deployment. If your volumes are larger than 15 TiB, creating them as [large volumes](https://cloud.google.com/netapp/volumes/docs/configure-and-use/volumes/overview#large-capacity-volumes) adds performance benefits. One limitation currently is that Slurm will only use the first IP of a large volume. If you need to utilize the full performance of the 6 IP addresses a large volume provides, you can instead utilize the approach with pre-existing volumes and CloudDNS mentioned in eda-hybrid-cloud blueprint description.
31+
32+
The cluster deployment group deploys a managed instance group which is managed by Slurm.
33+
34+
When scaling down the deployment, make sure to only destroy the *compute* deployment group. If you destroy the *base* group too, all the volumes will be deleted and you will lose your data.
35+
36+
### Blueprint [eda-hybrid-cloud](./eda-hybrid-cloud.yaml)
37+
38+
This blueprint assumes you are using NetApp Volumes [FlexCache](https://docs.cloud.google.com/netapp/volumes/docs/configure-and-use/volumes/cache-ontap-volumes/overview) to enable a [hybrid cloud EDA](https://community.netapp.com/t5/Tech-ONTAP-Blogs/NetApp-FlexCache-Enhancing-hybrid-EDA-with-Google-Cloud-NetApp-Volumes/ba-p/462768) environment.
39+
40+
The base deployment group (see [deployment stages](#deployment_stages)) connects to an existing network and mounts multiple volumes. This blueprint assumes you have pre-existing volumes for "tools", "libraries", "home" and "scratch". Before deployment, update `server_ip` and `remote_mount` parameters of the respective volumes in the blueprint declarations to reflect the actual IP and export path of your existing volumes. Using existing volumes also avoids the danger of being deleted accidentally when deleting the base deployment group.
41+
42+
The volumes used can be regular NetApp Volume [volumes](https://cloud.google.com/netapp/volumes/docs/configure-and-use/volumes/overview), [large volumes](https://cloud.google.com/netapp/volumes/docs/configure-and-use/volumes/overview#large-capacity-volumes) or [FlexCache volumes](https://cloud.google.com/netapp/volumes/docs/configure-and-use/volumes/cache-ontap-volumes/overview).
43+
44+
FlexCache offers the following features which enable bursting on-premises workloads into Google Cloud to use its powerful compute options:
45+
46+
- Read-writable sparse volume
47+
- Block-level, “pull only” paradigm
48+
- 100% consistent, coherent, current
49+
- write-around
50+
- LAN-like latencies after first read
51+
- Fan-out. Use multiple caches to scale out workload
52+
53+
It can accelerate metadata- or throughput-heavy read workloads considerably.
54+
55+
FlexCache and Large Volumes offer six IP addresses per volume which all provide access to the same data. Currently Cluster Toolkit only uses one of these IPs. Support for using all 6 IPs is planned for a later release. To spread your compute nodes over all IPs today, you can use CloudDNS to create an DNS record with all 6 IPs and specify that DNS name instead of individual IPs in the blueprint. CloudDNS will return one of the 6 IPs in a round-robin fashion on lookups.
56+
57+
The cluster deployment group deploys a managed instance group which is managed by Slurm.
58+
59+
## Getting Started
60+
To explore the reference architecture, you should follow these steps:
61+
62+
Before you start, make sure your prerequisites and dependencies are set up:
63+
[Set up Cluster Toolkit](https://cloud.google.com/cluster-toolkit/docs/setup/configure-environment).
64+
65+
For deploying the EDA reference blueprint follow the
66+
[Deployment Instructions](#deployment-instructions).
67+
68+
### Deployment Stages
69+
70+
This blueprint has the following deployment groups:
71+
72+
- `base`: Setup backbone infrastructure such as networking and file systems
73+
- `software_installation`(_optional_): This deployment group is a stub for
74+
custom software installation on the network storage before the cluster is brought up
75+
- `cluster`: Deploys an auto-scaling cluster
76+
77+
Having multiple deployment groups decouples the life cycle of some
78+
infrastructure. For example a) you can tear down the cluster while leaving the
79+
storage intact and b) you can build software before you deploy your cluster.
80+
81+
## Deployment Instructions
82+
83+
> [!WARNING]
84+
> Installing this blueprint uses the following billable components of Google
85+
> Cloud:
86+
>
87+
> - Compute Engine
88+
> - NetApp Volumes
89+
>
90+
> To avoid continued billing after use closely follow the
91+
> [teardown instructions](#teardown-instructions). To generate a cost estimate based on
92+
> your projected usage, use the [pricing calculator](https://cloud.google.com/products/calculator).
93+
>
94+
> [!WARNING]
95+
> Before attempting to execute the following instructions, it is important to
96+
> consider your project's quota. The blueprints create an
97+
> autoscaling cluster that, when fully scaled up, can deploy many powerful VMs.
98+
>
99+
> This is merely an example for an instance of this reference architecture.
100+
> Node counts can easily be adjusted in the blueprint.
101+
102+
1. Clone the repo
103+
104+
```bash
105+
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git
106+
cd cluster-toolkit
107+
```
108+
109+
1. Build the Cluster Toolkit
110+
111+
```bash
112+
make
113+
```
114+
115+
1. Change parameters in your blueprint file to reflect your requirements. Examples are VPC names for existing networks, H4D instance group node limits or export paths of existing NFS volumes.
116+
117+
1. Generate the deployment folder after replacing `<blueprint>` with the name of the blueprint (`eda-all-on-cloud` or `eda-hybrid-cloud`) and `<project_id>`, `region` and `zone` with your project details.
118+
119+
```bash
120+
./gcluster create community/examples/eda/<blueprint>.yaml --vars "project_id=${GOOGLE_CLOUD_PROJECT}" --vars region=us-central1 --vars zone=us-central1-a
121+
```
122+
123+
1. Deploy the `base` group
124+
125+
Call the following gcluster command to deploy the blueprint.
126+
127+
```bash
128+
./gcluster deploy CLUSTER-NAME
129+
```
130+
131+
Replace `CLUSTER-NAME` with the deployment_name (`eda-all-on-cloud` or
132+
`eda-hybrid-cloud`) used in the blueprint vars block.
133+
134+
The next `gcluster` prompt will ask you to **display**, **apply**, **stop**, or
135+
**continue** without applying the `base` group. Select 'apply'.
136+
137+
This group will create a network and file systems to be used by the cluster.
138+
139+
> [!WARNING]
140+
> This gcluster command will run through 2 deployment groups (3 if you populate
141+
> & activate the `software_installation` stage) and prompt you to apply each one.
142+
> If the command is cancelled or exited by accident before finishing, it can
143+
> be rerun to continue deploying the blueprint.
144+
145+
1. Deploy the `software_installation` group (_optional_).
146+
147+
> [!NOTE]
148+
> Installation processes differ between applications. Some come as a
149+
> precompiled binary with all dependencies included, others may need to
150+
> be built from source, while others can be deployed through package
151+
> managers such as spack. This deployment group is intended to be used
152+
> if the software installation process requires substantial amount of time (e.g.
153+
> compilation from source). By building the software in a separate
154+
> deployment group, this process can be done before the cluster is
155+
> up, minimizing costs.
156+
>
157+
> [!NOTE]
158+
> By default, this deployment group is disabled in the reference design. See
159+
> [Software Installation Patterns](#software-installation-patterns) for more information.
160+
161+
If this deployment group is used (needs to be uncommented in the blueprint first),
162+
you can return to the gcluster command which will ask you to **display**, **apply**,
163+
**stop**, or **continue** without applying the `software_installation` group.
164+
Select 'apply'.
165+
166+
1. Deploy the `cluster` group
167+
168+
The next `gcluster` prompt will ask you to **display**, **apply**, **stop**, or
169+
**continue** without applying the `cluster` group. Select 'apply'.
170+
171+
This deployment group contains the Slurm cluster and compute partitions.
172+
173+
## Teardown Instructions
174+
175+
> [!NOTE]
176+
> If you created a new project for testing of the EDA solution, the easiest way to
177+
> eliminate billing is to delete the project.
178+
179+
When you would like to tear down the deployment, each stage must be destroyed.
180+
Since the `software_installation` and `cluster` depend on the network deployed
181+
in the `base` stage, they must be destroyed first. You can use the following
182+
commands to destroy the deployment in this reverse order. You will be prompted
183+
to confirm the deletion of each stage.
184+
185+
```bash
186+
./gcluster destroy CLUSTER-NAME
187+
```
188+
189+
Replace `CLUSTER-NAME` with the deployment_name (`eda-all-on-cloud` or
190+
`eda-hybrid-cloud`) used in the blueprint vars block.
191+
192+
> [!WARNING]
193+
> If you do not destroy all three deployment groups then there may be continued
194+
> associated costs.
195+
196+
## Software Installation Patterns
197+
198+
This section is intended to illustrate how software can be installed in the context
199+
of the EDA reference solution.
200+
201+
Depending on the software you want to use, different installation paths may be required.
202+
203+
- **Installation with binary**
204+
Commercial-off-the-shelf applications typically come with precompiled binaries which
205+
are provided by the ISV. If you do not share them using the toolsfs or libraryfs shares,
206+
you can install software using the following method.
207+
208+
In general, you need to bring the binaries to your EDA cluster for which it is
209+
useful to use a Google Cloud Storage bucket, which is accessible from any machine using the
210+
gsutil command and which can be mounted in the cluster.
211+
212+
As this installation process only needs to be done once and at the same time may require time,
213+
we recommend to do this installation in a separate deployment group before you bring up the cluster.
214+
The `software_installation` stage is meant to accommodate this. You can for example bring up
215+
a dedicated VM
216+
217+
``` {.yaml}
218+
- id: sw-installer-vm
219+
source: modules/compute/vm-instance
220+
use: [network1, toolsfs]
221+
settings:
222+
name_prefix: sw-installer
223+
add_deployment_name_before_prefix: true
224+
threads_per_core: 2
225+
machine_type: c2-standard-16
226+
```
227+
228+
where you can follow the installation steps manually. Or using the toolkit's
229+
[startup-script](../../modules/scripts/startup-scripts/README.md) module, the process
230+
can be automated.
231+
232+
Once that is completed, the software will persist on the NetApp Volumes share for as long as you
233+
do not destroy the `base` stage.
234+
235+
- **Installation from source/with package manager**
236+
For open source software, you may want to compile the software from scratch or use a
237+
package manager such as spack for the installation. This process typically takes
238+
a non-negligible amount of time (~hours). We therefore strongly suggest to use
239+
the `software_installation` stage for this purpose.
240+
241+
Please see the [HCLS Blueprint](../../docs/videos/healthcare-and-life-sciences/README.md) example
242+
for how the `software_installation` stage can be used to use the spack package manager
243+
to install all dependencies for a particular version of the software, including compiling
244+
the software or its dependencies from source.
245+
246+
Please also see the [OpenFOAM](../../docs/tutorials/openfoam/spack-openfoam.md) example
247+
for how this can be used to install the OpenFOAM software.
248+
249+
Once that is completed, the software will persist on the NetApp Volumes share for as long as you
250+
do not destroy the `base` stage.

0 commit comments

Comments
 (0)