Skip to content

Commit 6033279

Browse files
okrauseokrause
committed
Adds two new blueprints for all-in-cloud and hybrid-cloud EDA workloads
1 parent ce46be9 commit 6033279

File tree

6 files changed

+743
-2
lines changed

6 files changed

+743
-2
lines changed

‎community/examples/eda/README.md‎

Lines changed: 251 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,251 @@
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 NetApp Volumes 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 NetApp Volumes 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+
It can accelerate metadata- or throughput-heavy read workloads considerably.
55+
56+
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.
57+
58+
The cluster deployment group deploys a managed instance group which is managed by Slurm.
59+
60+
## Getting Started
61+
To explore the reference architecture, you should follow these steps:
62+
63+
Before you start, make sure your prerequisites and dependencies are set up:
64+
[Set up Cluster Toolkit](https://cloud.google.com/cluster-toolkit/docs/setup/configure-environment).
65+
66+
For deploying the EDA reference blueprint follow the
67+
[Deployment Instructions](#deployment-instructions).
68+
69+
### Deployment Stages
70+
71+
This blueprint has the following deployment groups:
72+
73+
- `base`: Setup backbone infrastructure such as networking and file systems
74+
- `software_installation`(_optional_): This deployment group is a stub for
75+
custom software installation on the network storage before the cluster is brought up
76+
- `cluster`: Deploys an auto-scaling cluster
77+
78+
Having multiple deployment groups decouples the life cycle of some
79+
infrastructure. For example a) you can tear down the cluster while leaving the
80+
storage intact and b) you can build software before you deploy your cluster.
81+
82+
## Deployment Instructions
83+
84+
> [!WARNING]
85+
> Installing this blueprint uses the following billable components of Google
86+
> Cloud:
87+
>
88+
> - Compute Engine
89+
> - NetApp Volumes
90+
>
91+
> To avoid continued billing after use closely follow the
92+
> [teardown instructions](#teardown-instructions). To generate a cost estimate based on
93+
> your projected usage, use the [pricing calculator](https://cloud.google.com/products/calculator).
94+
>
95+
> [!WARNING]
96+
> Before attempting to execute the following instructions, it is important to
97+
> consider your project's quota. The blueprints create an
98+
> autoscaling cluster that, when fully scaled up, can deploy many powerful VMs.
99+
>
100+
> This is merely an example for an instance of this reference architecture.
101+
> Node counts can easily be adjusted in the blueprint.
102+
103+
1. Clone the repo
104+
105+
```bash
106+
git clone https://github.com/GoogleCloudPlatform/cluster-toolkit.git
107+
cd cluster-toolkit
108+
```
109+
110+
1. Build the Cluster Toolkit
111+
112+
```bash
113+
make
114+
```
115+
116+
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.
117+
118+
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.
119+
120+
```bash
121+
./gcluster create community/examples/eda/<blueprint>.yaml --vars "project_id=${GOOGLE_CLOUD_PROJECT}" --vars region=us-central1 --vars zone=us-central1-a
122+
```
123+
124+
1. Deploy the `base` group
125+
126+
Call the following gcluster command to deploy the blueprint.
127+
128+
```bash
129+
./gcluster deploy CLUSTER-NAME
130+
```
131+
132+
Replace `CLUSTER-NAME` with the deployment_name (`eda-all-on-cloud` or
133+
`eda-hybrid-cloud`) used in the blueprint vars block.
134+
135+
The next `gcluster` prompt will ask you to **display**, **apply**, **stop**, or
136+
**continue** without applying the `base` group. Select 'apply'.
137+
138+
This group will create a network and file systems to be used by the cluster.
139+
140+
> [!WARNING]
141+
> This gcluster command will run through 2 deployment groups (3 if you populate
142+
> & activate the `software_installation` stage) and prompt you to apply each one.
143+
> If the command is cancelled or exited by accident before finishing, it can
144+
> be rerun to continue deploying the blueprint.
145+
146+
1. Deploy the `software_installation` group (_optional_).
147+
148+
> [!NOTE]
149+
> Installation processes differ between applications. Some come as a
150+
> precompiled binary with all dependencies included, others may need to
151+
> be built from source, while others can be deployed through package
152+
> managers such as spack. This deployment group is intended to be used
153+
> if the software installation process requires substantial amount of time (e.g.
154+
> compilation from source). By building the software in a separate
155+
> deployment group, this process can be done before the cluster is
156+
> up, minimizing costs.
157+
>
158+
> [!NOTE]
159+
> By default, this deployment group is disabled in the reference design. See
160+
> [Software Installation Patterns](#software-installation-patterns) for more information.
161+
162+
If this deployment group is used (needs to be uncommented in the blueprint first),
163+
you can return to the gcluster command which will ask you to **display**, **apply**,
164+
**stop**, or **continue** without applying the `software_installation` group.
165+
Select 'apply'.
166+
167+
1. Deploy the `cluster` group
168+
169+
The next `gcluster` prompt will ask you to **display**, **apply**, **stop**, or
170+
**continue** without applying the `cluster` group. Select 'apply'.
171+
172+
This deployment group contains the Slurm cluster and compute partitions.
173+
174+
## Teardown Instructions
175+
176+
> [!NOTE]
177+
> If you created a new project for testing of the EDA solution, the easiest way to
178+
> eliminate billing is to delete the project.
179+
180+
When you would like to tear down the deployment, each stage must be destroyed.
181+
Since the `software_installation` and `cluster` depend on the network deployed
182+
in the `base` stage, they must be destroyed first. You can use the following
183+
commands to destroy the deployment in this reverse order. You will be prompted
184+
to confirm the deletion of each stage.
185+
186+
```bash
187+
./gcluster destroy CLUSTER-NAME
188+
```
189+
190+
Replace `CLUSTER-NAME` with the deployment_name (`eda-all-on-cloud` or
191+
`eda-hybrid-cloud`) used in the blueprint vars block.
192+
193+
> [!WARNING]
194+
> If you do not destroy all three deployment groups then there may be continued
195+
> associated costs.
196+
197+
## Software Installation Patterns
198+
199+
This section is intended to illustrate how software can be installed in the context
200+
of the EDA reference solution.
201+
202+
Depending on the software you want to use, different installation paths may be required.
203+
204+
- **Installation with binary**
205+
Commercial-off-the-shelf applications typically come with precompiled binaries which
206+
are provided by the ISV. If you do not share them using the toolsfs or libraryfs shares,
207+
you can install software using the following method.
208+
209+
In general, you need to bring the binaries to your EDA cluster for which it is
210+
useful to use a Google Cloud Storage bucket, which is accessible from any machine using the
211+
gsutil command and which can be mounted in the cluster.
212+
213+
As this installation process only needs to be done once and at the same time may require time,
214+
we recommend to do this installation in a separate deployment group before you bring up the cluster.
215+
The `software_installation` stage is meant to accommodate this. You can for example bring up
216+
a dedicated VM
217+
218+
``` {.yaml}
219+
- id: sw-installer-vm
220+
source: modules/compute/vm-instance
221+
use: [network1, toolsfs]
222+
settings:
223+
name_prefix: sw-installer
224+
add_deployment_name_before_prefix: true
225+
threads_per_core: 2
226+
machine_type: c2-standard-16
227+
```
228+
229+
where you can follow the installation steps manually. Or using the toolkit's
230+
[startup-script](../../modules/scripts/startup-scripts/README.md) module, the process
231+
can be automated.
232+
233+
Once that is completed, the software will persist on the NetApp Volumes share for as long as you
234+
do not destroy the `base` stage.
235+
236+
- **Installation from source/with package manager**
237+
For open source software, you may want to compile the software from scratch or use a
238+
package manager such as spack for the installation. This process typically takes
239+
a non-negligible amount of time (~hours). We therefore strongly suggest to use
240+
the `software_installation` stage for this purpose.
241+
242+
Please see the [HCLS Blueprint](../../docs/videos/healthcare-and-life-sciences/README.md) example
243+
for how the `software_installation` stage can be used to use the spack package manager
244+
to install all dependencies for a particular version of the software, including compiling
245+
the software or its dependencies from source.
246+
247+
Please also see the [OpenFOAM](../../docs/tutorials/openfoam/spack-openfoam.md) example
248+
for how this can be used to install the OpenFOAM software.
249+
250+
Once that is completed, the software will persist on the NetApp Volumes share for as long as you
251+
do not destroy the `base` stage.

0 commit comments

Comments
 (0)