Plan a Lustre HA and DR Topology

Audit seven servers and map a Lustre HA and disaster recovery plan.

Introduction

30 Second Summary

Seven servers can look like plenty until one room loses power or two machines need the same storage at once. A recovery plan that treats every failure the same can make a bad day worse.

In this project, you will turn five local servers plus two remote servers into a reviewable Lustre high availability and disaster recovery blueprint. The blueprint uses server evidence to expose every missing safety requirement before anyone changes the live filesystem.

What You'll Build

During a design review, your saved draw.io diagram lets you point to the exact boundary between local service failover and remote site recovery.

By the end of this project, you'll have:

A seven-server topology that separates five local roles from two remote recovery roles across distinct failure domains.
An evidence-backed readiness assessment that marks shared storage, network redundancy, fencing, and failover capacity as Confirmed or Missing.
A remote recovery flow with named ownership plus RPO and RTO targets for a complete local-site loss.
Secret Mission: Run a tabletop drill for metadata failure, object-storage failure, and complete local-site loss to prove the design separates local failover from full-site recovery.

Do I need anything before starting?

You need a Mac plus administrative SSH credentials or equivalent console access for all seven servers. The audit leaves the live filesystem unchanged.

Before We Start

This checkpoint locks in a non-destructive seven-server Lustre HA and DR blueprint before you inspect the live environment. Administrative SSH credentials or equivalent console access let you validate five Local Site servers for local failover while the two Remote Site servers remain a separate human-authorized recovery domain.

Prepare the Audit Workspace

An audit needs a stable workspace before server evidence starts arriving. Without one, the blueprint can turn into unsaved notes with no dependable access check.

macOS Terminal checks the local OpenSSH client. draw.io gives the audit an editable canvas saved on your Mac.

Both actions stay read-only. Your live Lustre environment remains untouched.

In this step, get ready to:

Verify the local OpenSSH client in macOS Terminal.
Create a blank draw.io diagram using local device storage.
Save the blank diagram as lustre-ha-dr-topology.drawio on your Mac.

Verify the OpenSSH client

OpenSSH provides the local ssh client you will use during the server inventory. Its version check reads the client version without contacting a server.

Use the search control in the macOS menu bar to open the system search.
Type Terminal into the search field.
Select macOS Terminal from the search results.

Before you run the check, predict whether Terminal reports a version or an unavailable client.

Check the local OpenSSH client by running this command:

ssh -V

What does this command do?

The ssh command launches the OpenSSH remote login client.
The -V option displays the installed client version before exiting.
A version line confirms that the local client is available for the later inventory checks.

You should see a line containing an OpenSSH version. Your access path has passed its first check.

No version output?

If no version appears, confirm that you selected macOS Terminal from the system search results.

Ask for help to diagnose the OpenSSH client check.

Create a blank local diagram

draw.io can keep an editable diagram file on your local device without an account. Local storage keeps the audit artifact on your Mac.

Open https://app.diagrams.net in your browser.
Choose local device storage when draw.io asks where to keep diagram files.
Select Blank as the new diagram type.
Confirm the selection to load the editor.

You should see a blank editable canvas. No server or storage objects should be present.

Canvas not loading?

Reload the browser page if the editor does not appear. Choose local device storage again before selecting the blank diagram.

Ask for help to open a blank local draw.io diagram.

Save and verify the audit file

A named local file turns the empty canvas into an audit artifact you can reopen. The blank state gives the next step a clean starting point.

Select File from the draw.io top menu.
Select Save As.
Enter lustre-ha-dr-topology.drawio as the filename.
Choose a folder on your Mac for the diagram.
Confirm the save in your Mac file picker.

The diagram should now show the filename lustre-ha-dr-topology.drawio. The editable canvas should remain blank.

That is the workspace secured. Your blank diagram is now a local home for every piece of evidence you collect next.

Before the final check, predict whether either local check can alter a server.

Switch back to macOS Terminal from earlier.
Repeat the OpenSSH check by running this command:

ssh -V

What does this final check prove?

The command reads the local OpenSSH client version again. It confirms that the client remains available after the browser workspace has been created.

You should see an OpenSSH version again. No connection to any of the seven servers has occurred.

Return to the draw.io browser tab from earlier.
Use the draw.io file-open control to open lustre-ha-dr-topology.drawio from the local folder you chose.

You should see lustre-ha-dr-topology.drawio open as a blank editable canvas. No server, storage, network, or recovery-flow objects have been added.

Saved file not reopening?

Confirm that the filename ends with .drawio. Check the same local folder you selected during the save.

Ask for help to find and reopen the saved draw.io file.

Your audit workspace is saved. Next, you will turn the blank canvas into a seven-server evidence map.

Inventory All Seven Servers

Your saved draw.io canvas gives the audit a home. It needs evidence from the real servers before any Lustre role can be trusted.

In this step, you will use SSH plus read-only Linux commands to identify all seven servers. The visible inventory prevents the topology from being built around imagined hardware capabilities.

In this step, get ready to:

Capture the observed hostname plus the relevant address from every server.
Record visible filesystems plus mount points without changing storage.
Arrange five local servers plus two remote servers into their site boundaries.

Collect server identities and addresses

A logical audit label gives each box a stable place in the diagram. The observed hostname ties that box to a real machine.

You already have the approved access path, so this pass only reads identity data from each server. Administrative credentials stay outside the diagram.

Select the first server from your approved inventory.
Verify its identity against your organisation's records if SSH asks about an unfamiliar host.
Connect to the server with its administrative username plus hostname by running this command:

ssh user@hostname

What does this command do?

The ssh command starts an encrypted remote login session. The user@hostname destination identifies the account plus the server.

Complete authentication with the administrative credentials available from the previous step.

You should see an authenticated remote shell for the selected server.

Unable to reach a server?

Check the administrative username against your approved access records.
Confirm that your Mac can reach the server through the required network connection.
Use the equivalent console access path if your organisation blocks remote login.

If the connection still fails, help me diagnose the server access problem.

Collect the server name plus assigned interface addresses in the active remote session by running:

hostname
ip address show

What do these commands reveal?

The hostname command reports the system name configured on the server.
The ip address show command lists addresses assigned to the server's network interfaces.

Read the system name from the hostname output.
Identify the relevant management or data address using the interface output plus your approved network records.

How do the logical labels work?

The local sequence runs from Local Server 1 through Local Server 5.

The remote sequence runs from Remote Server 1 through Remote Server 2.

Switch back to the saved lustre-ha-dr-topology.drawio diagram.
Drag one rectangle from the shapes area on the left onto the canvas.
Assign the next unused logical label that matches the server's known site.
Add the observed hostname to the server box.
Add the known site to the server box.
Add the relevant management or data address to the server box.
Repeat the connection plus identity collection for the remaining six servers.
Save lustre-ha-dr-topology.drawio on your Mac.

After the seventh pass, you should see seven server boxes containing identity evidence.

Missing a hostname or address?

Confirm that you ran the inspection commands inside the remote server session.
Compare the listed interfaces with your approved network records.
Label an address purpose as unconfirmed when the available records do not identify it.

If the output is difficult to interpret, help me identify the relevant server address.

Record read-only storage evidence

Storage visibility helps you distinguish real target candidates from empty role assumptions. Filesystem details plus mount points provide evidence without changing the server.

Keep storage read-only

Seeing storage devices can make this part feel risky. This audit only reports the state that already exists.

Leave every filesystem format unchanged.
Leave every current mount state unchanged.

Return to the first server through the approved access path used earlier.
Inspect its visible filesystems plus mount points by running:

lsblk --fs

What does this command reveal?

The lsblk --fs command reports filesystem information for visible block devices. Its output includes mount-point information where available.

Labels plus mount points can suggest possible MGT, MDT, or OST use. Treat that use as possible until operational evidence confirms it.

Match the command output to the corresponding server box.
Add the visible filesystem details to its storage summary.
Add the observed mount points to its storage summary.
Note possible target use only where the evidence supports it.
Repeat the storage inspection for the remaining six servers.
Save the updated lustre-ha-dr-topology.drawio file.

Each server box should now contain a storage summary grounded in observed output.

Missing storage evidence?

Confirm that you ran the command on the Linux server instead of your Mac.
Use the approved console path if the remote shell restricts system inspection.
Ask the server administrator for the same read-only output if your account cannot inspect block devices.

If a device or mount point remains unclear, help me interpret the storage inventory safely.

Classify roles and arrange failure domains

A failure domain groups machines that can be affected by the same site-level event. The site boundaries make the local and remote split visible.

Current roles must come from observed evidence or existing operational records. The label Unassigned keeps uncertainty visible.

Review the collected evidence plus approved operational records for each server.
Write the observed current Lustre role inside each server box.
Enter Unassigned when the current role cannot be confirmed.
Add a boundary labelled Local Site to the canvas.
Move the five local server boxes inside the Local Site boundary.
Add a boundary labelled Remote Site to the canvas.
Move the two remote server boxes inside the Remote Site boundary.
Save lustre-ha-dr-topology.drawio on your Mac.

Before you count the boxes, how many do you expect inside each site boundary?

Count every server box in the diagram.
Inspect each box against the required inventory fields.

What should you see?

Five uniquely named boxes sit inside Local Site.
Two uniquely named boxes sit inside Remote Site.
Every box displays its observed hostname.
Every box displays its site.
Every box displays a relevant management or data address.
Every box displays its current Lustre role or Unassigned.
Every box displays visible filesystem plus mount-point evidence.
Possible target notes name MGT, MDT, or OST only where evidence supports them.

Strong work. Your blueprint now represents seven real servers instead of seven assumed capabilities.

Next, you will test the tempting two-server remote HA idea. The diagram will make its capacity gap visible.

Expose the Remote HA Gap

Your saved draw.io diagram now anchors all seven server boxes to observed evidence. A convincing layout can still reuse the same machines for incompatible responsibilities.

The Remote Site proposal needs a capacity test against Lustre's metadata high availability block. The key question is whether the same two nodes can independently supply that block plus the separate object-storage block.

In this step, get ready to:

Group the two remote servers as one temporary HA Pair.
Test that pair against separate MGS/MDS Pair plus OSS Pair requirements.
Record uncovered capacity plus unconfirmed safety gates as Missing.

Group the remote servers for the test

The MGS/MDS Pair represents the two-server metadata plus management building block. Its shared targets are the MGT plus any MDT targets.

The OSS Pair represents a separate two-server object-storage building block. Its members need access to the same OST targets.

Why two requirement boxes?

The minimum Lustre HA shape contains one metadata plus management group. It also contains a separate object-storage group.

Each group needs two servers with access to its shared storage. Keeping the boxes separate makes the hardware demand visible.

Every action in this step stays inside the diagram. Your live servers plus storage targets remain untouched.

Switch back to the saved lustre-ha-dr-topology.drawio diagram in draw.io.
Drag a container shape from the left panel around Remote Server 1 plus Remote Server 2.
Type HA Pair into the container.

You should see both remote server boxes enclosed by one temporary container labeled HA Pair.

Change the container border to a dashed style using the format panel on the right.
Drag a rectangle from the left panel beside the temporary group.

You should see a dashed proposal boundary beside one empty requirement box.

Type MGS/MDS Pair into the requirement box.
Duplicate the MGS/MDS Pair box.

You should see two identical requirement boxes beside the temporary pair.

Replace the duplicated label with OSS Pair.
Place the OSS Pair box below the MGS/MDS Pair box.

The Remote Site now shows one available pair beside two separate two-server requirements.

Save lustre-ha-dr-topology.drawio by pressing Cmd+S on macOS or Ctrl+S on Windows.

Connect the available pair and expose the gap

Before you draw the connectors, predict whether one two-server pair can fill both independent requirements. Hold that prediction while you test the layout.

Draw a connector from Remote Server 1 to MGS/MDS Pair.
Draw a connector from Remote Server 2 to MGS/MDS Pair.

The MGS/MDS Pair requirement now consumes both remote servers. The separate OSS Pair remains uncovered.

What does the conflict prove?

That conflict is the evidence you needed. The two remote servers can fill one two-node HA block.

A separate OSS block still needs two servers. The Remote Site therefore cannot supply both independent blocks.

Add Missing beneath OSS Pair inside the uncovered requirement box.
Set the Missing text to red.

You should now see the uncovered object-storage requirement marked Missing in red.

What counts as confirmed?

Shared-target visibility is confirmed only when recorded evidence shows both servers can access the same candidate target. A possible target shown on one server does not prove pair visibility.

Fencing is confirmed only when evidence identifies an independent isolation path. That path cannot depend solely on the protected node's network or power source.

Add Remote shared-target visibility: Confirmed only when the recorded inventory proves access from both remote servers. Otherwise add Remote shared-target visibility: Missing.
Add Independent fencing: Confirmed only when the recorded inventory proves an independent isolation path. Otherwise add Independent fencing: Missing.

The two readiness labels now show which safety claims have evidence. Any unsupported claim reads Missing.

Set every readiness label containing Missing to red.
Save lustre-ha-dr-topology.drawio by pressing Cmd+S on macOS or Ctrl+S on Windows.

Before the final review, predict whether any readiness gate can remain Confirmed without matching inventory evidence. Use that prediction to audit each label.

Inspect the Remote Site boundary in the saved diagram.
Count the server boxes inside the temporary HA Pair.
Compare those two servers with the two separate requirement boxes.
Confirm that the uncovered OSS Pair is marked Missing in red.
Match each remote readiness label against the recorded server evidence.

You should see exactly two remote servers supplying the MGS/MDS Pair requirement. The separate OSS Pair should remain Missing in red.

Remote shared-target visibility should read Missing unless the inventory directly proves it. Independent fencing should follow the same evidence rule.

Gap still unclear?

Keep both remote server connectors attached to MGS/MDS Pair.
Leave OSS Pair without server connectors.
Use help me make the two-server HA shortfall clear in my draw.io diagram.

The remote proposal now has an evidence-backed capacity gap. Next, you will use the five Local Site servers to create both HA building blocks plus a dedicated client role.

Build the Local HA Topology

The remote-site sketch has exposed the capacity gap. Two remote servers cannot cover both required Lustre HA building blocks.

The five local servers can place service failover close to shared targets in the draw.io diagram. You will assign two local pairs plus the client before testing the design against recorded evidence.

In this step, get ready to:

Assign the five local servers to metadata, object-storage, or client roles.
Map the local shared targets to both peers in each pair.
Grade four readiness gates using the inventory evidence.

Assign the five local roles

The local design needs two independent failover pairs plus one client. Fixed assignments keep every server accountable during the topology review.

Switch back to the saved lustre-ha-dr-topology.drawio diagram in the browser tab from earlier.
Add a design assignment line containing MGS/MDS HA Pair inside the Local Server 1 box.
Add a design assignment line containing MGS/MDS HA Pair inside the Local Server 2 box.
Add a design assignment line containing OSS HA Pair inside the Local Server 3 box.
Add a design assignment line containing OSS HA Pair inside the Local Server 4 box.
Add a design assignment line containing Lustre Client inside the Local Server 5 box.
Save your changes to lustre-ha-dr-topology.drawio.

You should see two local metadata members plus two local object-storage members. The fifth local box provides the client role.

How Do the Local Roles Fit Together?

The MGS manages the filesystem configuration. The MDS serves filesystem metadata from the assigned metadata targets.

Each OSS serves data from its assigned OST resources. The Lustre Client provides a client-facing place to check access during a future controlled test.

Can't Match a Role to a Server?

Check that every local box still contains its recorded site, address, current role, and storage summary. Move any detached assignment label inside the correct server box.

If the assignments still look unclear, help me review my five local Lustre role assignments.

Map the shared storage

Shared-storage failover depends on both peers reaching the same target. Each target must remain active on one peer at a time.

Drag a storage shape from the palette beside the canvas to a position beneath Local Server 1 inside the Local Site boundary.
Set the storage shape label to MGT and MDT.
Draw a connector from MGT and MDT to Local Server 1.
Draw a connector from MGT and MDT to Local Server 2.
Add Mounted by one server at a time beneath the MGT and MDT label.
Save your changes to lustre-ha-dr-topology.drawio.

You should see one metadata storage object connected to both members of the local metadata pair.

Why One Active Mount?

The MGT plus MDT targets are the failover resources. Their services follow the peer that mounts the corresponding target.

The single-active label records a key safety condition. It prevents reviewers from treating simultaneous target access as a valid failover design.

Drag a separate storage shape from the palette beside the canvas to a position beneath Local Server 3 inside the Local Site boundary.
Set the second storage shape label to OSTs.
Draw a connector from OSTs to Local Server 3.
Draw a connector from OSTs to Local Server 4.
Add Mounted by one server at a time beneath the OSTs label.
Save your changes to lustre-ha-dr-topology.drawio.

You should now see a separate object-storage target group connected to both members of the local object-storage pair.

Do the Storage Connections Look Ambiguous?

Check that the MGT and MDT object connects only to Local Server 1 plus Local Server 2.

Check that the OSTs object connects only to Local Server 3 plus Local Server 4. If a line still points to the wrong box, help me correct my shared-storage connectors.

Evaluate the local readiness gates

Readiness gates separate a plausible drawing from an evidence-based plan. A gate earns Confirmed only when the recorded inventory proves its requirement.

Add four small gate boxes along the bottom of the Local Site boundary.
Label the first gate Shared-target visibility.
Label the second gate Redundant cluster communication.
Label the third gate Independent fencing.
Label the fourth gate Failover capacity.

You should now see four unanswered safety questions beside the proposed local topology.

What Does Independent Fencing Prove?

Fencing isolates a failed or untrusted node before a shared target starts elsewhere. This prevents split-brain access from corrupting or diverging shared data.

An independent fencing path cannot depend solely on the same network or power source as the node it protects. Evidence must show a separate control path before this gate becomes Confirmed.

Mark all four readiness gates Missing as the evidence-first baseline.
Change Shared-target visibility to Confirmed only if the collected evidence proves that both members of each pair can access the intended target.
Change Redundant cluster communication to Confirmed only if the collected evidence proves redundant communication paths for each local pair.
Change Independent fencing to Confirmed only if the collected evidence proves an independent isolation path.
Change Failover capacity to Confirmed only if the inventory proves each surviving peer can carry its partner's assigned target service.
Save your changes to lustre-ha-dr-topology.drawio.

Before you inspect the finished Local Site, do you expect every gate to read Confirmed or will the evidence leave one or more gates Missing?

Count the five assigned server boxes inside the Local Site boundary.
Trace both connectors from MGT and MDT to the metadata pair.
Trace both connectors from OSTs to the object-storage pair.
Read the status on each of the four readiness gates.
Inspect the Remote Site boundary to confirm the temporary HA comparison remains visible.

What Should I See?

You should see Local Server 1 plus Local Server 2 assigned to MGS/MDS HA Pair. Local Server 3 plus Local Server 4 belong to OSS HA Pair. Local Server 5 is the Lustre Client.

The MGT and MDT object connects to both metadata peers. The separate OSTs object connects to both object-storage peers.

Every storage object reads Mounted by one server at a time. Every readiness gate reads either Confirmed or Missing.

The Remote Site still shows the temporary comparison plus the red Missing capacity gap. No live Lustre, storage, network, fencing, or failover configuration has changed.

Unsure Whether a Gate Is Confirmed?

Leave the gate Missing whenever the evidence is incomplete. A plausible assumption does not prove readiness.

For shared-target visibility, require evidence from both peers in the relevant pair. If you need help judging the recorded evidence, help me classify my local HA readiness gates.

Solid work. The local blueprint now separates proven readiness from blockers that still need evidence. Next, you will turn the remote servers into a disaster recovery path outside the local failover control plane.

Assign the Remote DR Roles

Your draw.io diagram now proves that the five local servers can support the proposed Lustre layout. The remaining two servers need roles that preserve a recovery path after the local site becomes unavailable.

Disaster recovery protects against complete site loss. The remote site remains a separate failure domain because the wide-area network has not been validated for automatic failover.

This step changes only the saved architecture diagram. You will define the remote recovery flow without changing any live server configuration.

In this step, get ready to:

Assign a recovery role to each remote server.
Map the one-way recovery path between sites.
Document the conditions for authorized remote recovery.

Assign the remote recovery roles

A recovery copy preserves the data needed to rebuild service after local-site loss. The second remote server checks that restored data can be accessed from the recovery location.

Select the Remote Server 1 box inside Remote Site.
Replace its temporary comparison role with Remote Recovery Copy.
Select the Remote Server 2 box inside Remote Site.
Replace its temporary comparison role with Recovery Validation and Remote Client.

Good progress. You should see Remote Server 1 labeled Remote Recovery Copy.

You should see Remote Server 2 labeled Recovery Validation and Remote Client.

Draw the one-way recovery flow

A one-way arrow makes the recovery direction explicit. The exact copy mechanism stays pending until the audit details support a safe choice.

Draw a one-way arrow from the local Lustre system to Remote Recovery Copy.
Label the arrow Pending OS, backend, and recovery-policy selection.

You should see the arrowhead pointing into Remote Recovery Copy. Its label records that the implementation choice still depends on the environment evidence.

Draw a restore-validation arrow from Remote Recovery Copy to Recovery Validation and Remote Client.
Label the arrow Restore validation.

You should now see a directional recovery chain from the local system to the recovery copy. The chain ends at the validation server.

Why Keep the HA Ring Local?

The remote site handles recovery after complete local-site loss. The design leaves Pacemaker outside the cross-city path.

It also leaves Corosync outside that path. This prevents the diagram from implying an automatic cluster relationship that the audit has not validated.

Document recovery decisions

A recovery point objective defines the accepted data-loss window. A recovery time objective defines the restoration-time target.

Record the accepted data-loss target you choose here: your chosen RPO target.
Record the restoration-time target you choose here: your chosen RTO target.

Your recorded targets now give the recovery workflow measurable boundaries.

Record the person or role authorized to declare a disaster here: your disaster declaration owner.

What Belongs in the Recovery Note?

Use RPO: your chosen RPO target.
Use RTO: your chosen RTO target.
Use Disaster declaration owner: your disaster declaration owner.

Add one text note inside Remote Site containing the three decision fields above.
Label the Remote Site boundary No automatic cross-city HA failover.

You should see the recovery targets beside a named decision owner. The site boundary should state where automatic failover stops.

Select File from the top menu in draw.io.
Select Save As.

You should now see the local save flow for the editable diagram.

Save the updated diagram as lustre-ha-dr-topology.drawio on your Mac.

Before you inspect the finished diagram, do you expect any path to authorize automatic failover between cities? Hold that prediction for the check.

Inspect the saved Remote Site section in draw.io.
Trace each recovery arrow from its source to its arrowhead.
Check the diagram for any Pacemaker or Corosync connection between cities.

You should see Remote Server 1 assigned to Remote Recovery Copy. You should see Remote Server 2 assigned to Recovery Validation and Remote Client.

You should see a one-way arrow from the local Lustre system to the recovery copy. Its label should read Pending OS, backend, and recovery-policy selection.

You should see a restore-validation arrow leading to the second remote server. The diagram should also show your chosen RPO target.

You should see your chosen RTO target beside a named Disaster declaration owner.

You should find no Pacemaker or Corosync HA ring between cities. Your live systems remain unchanged.

That completes the blueprint. Your design now separates local service failover from authorized remote recovery.

Secret mission

Run a Tabletop Failure Drill

Your topology shows where each server belongs. Now turn it into a decision aid by tracing two local failovers and one complete site-loss recovery without touching the live filesystem.

Clean Up Your Resources

This audit created no billable resources, so it has no ongoing cost. Your saved diagram is the only teardownable artifact because the live Lustre environment stayed unchanged.

Resources you used:

The locally saved editable lustre-ha-dr-topology.drawio file created with draw.io.

Keep everything running

No cleanup action is needed. Choose this if you want to keep the blueprint for deployment planning or future reviews.

Keep lustre-ha-dr-topology.drawio at its current saved location.
Preserve its inventory evidence, readiness labels, recovery objectives, and tabletop runbook for the follow-on deployment.

Pause - I'll come back to this later

Close the browser editor while preserving your saved work. There are no server processes or live tests to stop.

Save any final edits to the existing lustre-ha-dr-topology.drawio file.
Close the browser tab containing draw.io.
Keep the diagram at its current saved location for your next review.

Delete - I don't want to use this again

This command permanently removes only the diagram path you provide. It does not contact any of the seven servers.

Record the diagram's full saved path here: path to lustre-ha-dr-topology.drawio.
Delete the diagram at that path by running this command:

rm "[[DIAGRAM_PATH="path to lustre-ha-dr-topology.drawio"]]"

What Does This Command Do?

This command removes only the file at the path you entered. Quotation marks keep a path containing spaces together as one file location.

Return to the folder that previously held lustre-ha-dr-topology.drawio using your Mac's file browser.

You should no longer see lustre-ha-dr-topology.drawio in that folder. Your seven servers remain unchanged.

Diagram Still Present?

Check that the recorded path ends with lustre-ha-dr-topology.drawio.
Confirm that the path points to the folder where you originally saved the diagram.
Help me safely delete the saved draw.io file from macOS Terminal.

Nice Work!

Excellent work! Your editable Lustre blueprint now separates local high availability from remote disaster recovery without changing the live filesystem.

You've learned how to:

Map a seven-server topology with two local HA pairs plus one local client. The two remote servers stay inside a separate recovery failure domain.
Turn server evidence into a readiness assessment for every local safety gate. Each gate carries a Confirmed or Missing result.
Define a one-way recovery flow with chosen RPO/RTO targets. A named owner controls recovery across the No automatic cross-city HA failover boundary.
Complete the Secret Mission with a non-destructive tabletop runbook for metadata failure, object-storage failure, and total Local Site loss. Each path names its safety action plus its observable recovery result.

Ready to quiz yourself?