Design a Proxmox VE Ceph Architecture

Create a review-ready Proxmox VE and Ceph HCI architecture package.

Introduction

30 Second Summary

Infrastructure diagrams can look convincing before anyone checks the evidence behind them. A tidy picture can still hide risky assumptions.

In this project, you will create a review-ready architecture package for a Proxmox VE environment using Ceph hyper-converged infrastructure. The package will separate current evidence from a production-aware target for a future Docker workload.

What You'll Build

You open a multi-page PDF that takes a reviewer from your real environment to a corrected production-aware target.

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

An evidence-led review path that shows where an attractive first draft conflicts with your real hardware.
A production-aware target diagram that makes separate Corosync, Ceph public, Ceph internal, and guest network paths visible alongside distributed MON, MGR, and OSD roles.
A workload placement story that shows the future Docker workload inside a QEMU VM backed by Ceph RBD, with unresolved requirements clearly identified.
Secret Mission: Add a failure-domain overlay that grays out one node while exposing untested assumptions and external single points of failure.

Are there any prerequisites?

You'll need credentials that can view a Proxmox VE environment with at least three nodes. The draw.io web editor runs in Microsoft Edge without an account or Ceph installation.

Before We Start

This step exists to lock in who will use the architecture package and which implementation decision it should support. Your commitment separates current evidence from a safe target design without changing the live Proxmox VE environment.

Set Up the Documentation Workspace

You have committed to separating current evidence from the target design. A local editable draw.io source gives you a safe place to plan before anyone changes live infrastructure.

Microsoft Edge keeps the planning canvas in one browser tab. A separate tab shows Proxmox VE Server View as your view-only reference.

In this step, get ready to:

Create a blank local draw.io source file.
Open the Proxmox VE web interface in a separate Microsoft Edge tab.
Confirm that Server View lists Datacenter plus at least three node objects.

Create the local draw.io source file

The Device storage option keeps your editable source on your computer. The native .drawio format preserves the diagram for later changes.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Microsoft Edge and press Enter to open it.

You will see a Microsoft Edge window ready for the documentation workspace.

Load the draw.io web editor by entering https://app.diagrams.net/ in the address bar.

You will see draw.io ask where it should store your diagram.

Select Device as the storage location.
Click Create New Diagram.

You will see the new diagram window with options for the file name and template.

Enter proxmox-hci-architecture.drawio as the file name.
Select Blank Diagram.

The new diagram is now configured to start without architecture objects.

Click Create.
Save the file locally when Microsoft Edge prompts you.

Good, your editable source is now open on a blank canvas. The cluster design has a safe local home before any infrastructure work begins.

✔️ The source file matches

Your blank canvas is ready. Keep proxmox-hci-architecture.drawio open in this tab.

ⓧ I'd like to double check the source file

Local editable draw.io source file named proxmox-hci-architecture.drawio, saved in default .drawio format, open on a blank canvas with no architecture pages or diagram objects yet.

Confirm that the file name is exactly proxmox-hci-architecture.drawio.
Confirm that the file uses the default .drawio format.
Confirm that the canvas contains no architecture objects.

File Name or Format Wrong?

Open the File menu in draw.io.
Select Save As.
Save the file as proxmox-hci-architecture.drawio in the default format.

Help me fix my local draw.io file name or format.

Open the view-only Proxmox tab

Opening a live cluster interface can feel high stakes. This pass uses navigation only so the environment stays unchanged.

Protect the Live Environment

Your architecture document depends on observed evidence. Any cluster change would break the safety boundary for this project.

Avoid every action that creates, joins, destroys, upgrades, or reconfigures a resource.

Open a new tab using the new tab button in the Microsoft Edge tab bar.
Load your existing Proxmox VE web interface from its approved bookmark or internal address.

You will see either the Proxmox VE sign-in page or the management interface.

You will see the management interface without making a cluster change.

Choose Server View from the view selector on the left.
Locate Datacenter in the object tree.
Count the node objects listed under Datacenter.

You should see Datacenter plus at least three node objects. That confirms the cluster reference is available for the architecture work.

Missing Nodes or Access?

Stop if Server View lists fewer than three node objects.
Ask the cluster owner to confirm that your approved address points to the intended Proxmox VE cluster.
Keep using view-only access while the cluster owner checks your permissions.

Help me troubleshoot missing Proxmox VE nodes without changing the cluster.

Verify the two-tab workspace

A safe starting point shows the blank local source beside the live view-only reference. Before you check both tabs, predict whether those two states will be visible at the same time.

Switch back to the draw.io tab in Microsoft Edge.

You should see proxmox-hci-architecture.drawio open on a blank canvas with no architecture objects.

Switch to the Proxmox VE tab in Microsoft Edge.

You should see Server View with Datacenter plus at least three node objects. You have verified the reference environment without changing Proxmox VE, Ceph, disks, networks, or cluster resources.

That setup is complete: your editable source is local while the cluster remains untouched. Next up, you will turn the blank canvas into the first-pass HCI model.

Draw the First-Pass HCI Model

Your editable source file is ready in draw.io. The Proxmox VE Server View remains available in another tab for reference.

Now you will turn the blank canvas into a first-pass hyper-converged infrastructure model. This deliberately simplified design gives the next audit something concrete to challenge.

In this step, get ready to:

Build a three-node first-pass frame.
Show one OSD disk per node through one shared network.
Place a future QEMU virtual machine for the Docker workload above Ceph RBD.

Build the three-node frame

Each large block represents one physical node in the environment. Consistent sizing makes the first-pass layout easier to compare later.

Double-click the current page tab below the canvas.
Replace the page name with First Pass.
Press Enter to confirm the page name.

You should see First Pass on the page tab below the canvas.

Drag three large rectangles from the shape library onto the canvas.
Arrange the rectangles in one horizontal row.
Name the blocks from left to right Node 1, Node 2, and Node 3.
Add Proxmox VE inside each node block.

You should see three matching node blocks across the First Pass page. Each block contains its node name plus Proxmox VE.

Add the simplified storage path

The draft models one storage disk inside each node. One common line stands in for every network path at this stage.

Drag one cylinder shape inside each node block.
Position each cylinder within its matching node boundary.
Label each cylinder OSD.
Draw one long horizontal line beneath the three node blocks.
Label the horizontal line Shared Network.
Connect each node block to the horizontal line with a connector.

You should see one OSD inside each node. All three nodes should connect to the same Shared Network line.

Place the future workload

Ceph RBD represents the storage backing the future virtual disk. The QEMU VM gives the Docker workload a boundary away from the hypervisor.

The VM is only a proposed placement. A visible qualifier keeps the diagram from implying that the workload already exists.

Add a central rectangular storage block beneath the Shared Network line.
Label the storage block Ceph RBD.
Add a smaller rectangle inside Node 1.
Label the smaller rectangle QEMU VM: Docker Workload.
Add Future, not deployed below the VM label.
Connect the VM block to Ceph RBD with a connector.

Before you inspect the finished page, predict whether this model will look production-ready at first glance.

Zoom out until the entire First Pass page fits on the canvas.
Review the complete page as one architecture model.

You should see three node blocks connected to one Shared Network. Each node contains Proxmox VE plus one OSD disk.

You should also see Ceph RBD connected to the proposed QEMU VM: Docker Workload block. The VM sits inside Node 1 with its future-workload qualifier.

The draft looks coherent at first glance. The single network is one intended shortfall.

The three-OSD design is another intended shortfall. You have now seen the simplified model before any correction is introduced.

Shapes or connectors out of place?

Drag any misplaced disk back inside its matching node boundary.
Move any loose connector endpoint onto the edge of its intended shape.
Resize the VM block if it overlaps the node label or its OSD disk.

Ask for help with the layout if the relationships remain unclear: Help me troubleshoot my first-pass Proxmox VE and Ceph diagram layout in draw.io.

Your first visible architecture model is complete. Next, you will audit its assumptions against current Proxmox VE and Ceph guidance.

Audit the Model Against Guidance

The First Pass page in draw.io now turns your three Proxmox VE nodes into a visible hyper-converged infrastructure model. The future Docker workload sits above Ceph RBD storage as a planned design.

The model looks complete at first glance. However, its Shared Network combines latency-sensitive traffic with high-bandwidth storage traffic.

Its three OSDs also fall short of the documented 12-OSD target. This audit turns both shortfalls into visible evidence.

In this step, get ready to:

Build a current-state inventory from view-only node evidence.
Compare the first-pass design with the documented Ceph baseline.
Annotate proven gaps without inventing missing facts.

Inspect the current environment

A current-state inventory records what your screens prove. Any unavailable detail becomes Unknown.

This inspection is a little fiddly because the facts are spread across several node views. Treat each field as a small evidence check.

Switch back to the Proxmox VE tab from earlier.
Select Datacenter in Server View.
Select Cluster.
Count the available node objects listed in the cluster.
Return to the draw.io tab from earlier.
Add a side panel titled Current-State Inventory to the First Pass page.
Create one inventory section for every available node.

Your side panel should now have a clearly labeled section for each node listed in the cluster.

What Counts as Current Evidence?

Current evidence comes from information visible in the Proxmox VE interface. Record exactly what you can observe.

Use Unknown when a view does not prove a value. This keeps assumptions out of the architecture package.

Switch back to the Proxmox VE tab.
Select the first node in Server View.
Record the installed Proxmox VE version from the node status in its matching inventory section.
Record the CPU summary from the node status.
Record the RAM summary from the node status.
Select System.
Record any visible NICs with their displayed speeds.
Select Disks.

The selected node now has compute evidence plus network evidence. Its storage evidence comes next.

Record any candidate data disks supported by the visible disk information.
Select Ceph where that section is available.
Record the observed Ceph status in the matching inventory section.
Enter Unknown for every detail that the available views do not prove.
Repeat this evidence pass for every remaining node.
Return to the draw.io tab.
Confirm that every node section records version, CPU, RAM, NICs, disks, and Ceph status.
Save proxmox-hci-architecture.drawio using draw.io's save control.

You should see a complete inventory section for every available node. Any missing fact should appear as Unknown.

Can't Find a Node Detail?

Compare the number of inventory sections with the node count shown under Cluster.
Record Unknown when the available views do not prove a hardware detail.
Record only what the interface proves about Ceph when its section is unavailable.

Help me verify which Proxmox VE details belong in each node inventory entry.

Compare the model with the baseline

The current Proxmox VE documentation gives your inventory a consistent comparison point. This audit uses version 9.2.4 as its documentation baseline.

The Ceph requirements below describe a production-aware target. They do not claim that your current hardware already meets it.

What Does the Audit Baseline Require?

Use at least three servers. Prefer identical servers.
Place three MONs for high availability plus quorum.
Place more than one MGR for manager availability.
Map one OSD to each physical disk.
Target at least 12 OSDs distributed evenly across the nodes.
Plan at least 8 GiB of memory per OSD for good performance.
Avoid RAID controllers before Ceph OSD disks.
Dedicate 10+ Gbps network capacity to Ceph traffic.

Return to the First Pass page in draw.io.
Add a second side panel titled Audit Baseline.
Record Documentation baseline: Proxmox VE 9.2.4 at the top of the panel.
Record each criterion from the baseline callout in the panel.
Compare each observed node version with version 9.2.4.
Add a red version gap only when an observed installed version differs from the documentation baseline.
Save proxmox-hci-architecture.drawio.

You should now see the documentation version plus all eight readiness criteria beside your current-state inventory.

Mark proven gaps

A red Gap callout ties one visible design choice to one documented shortfall. The first-pass model proves two such shortfalls without relying on unknown hardware facts.

When Does Hardware Become a Gap?

Observed evidence supports a hardware-specific gap when it conflicts with the baseline. Examples include insufficient NIC speed, insufficient memory for the planned OSD count, a RAID controller before OSD disks, or too few candidate disks for an evenly distributed target.

An Unknown field supports only a Needs validation label. This prevents a missing fact from becoming a false conclusion.

Add a callout beside the Shared Network line.
Color the shared-network callout red.
Label it Gap: Combined Shared Network.
Add a callout beside the three existing OSD disks.
Color the OSD callout red.
Label it Gap: Three OSDs vs 12-OSD target.

You should now see two red callouts attached to the deliberately weak choices in the first-pass model.

Review every inventory field against the matching audit criterion.
Add a red hardware-specific gap only where observed evidence proves a mismatch.
Add Needs validation beside every unverified item.
Save proxmox-hci-architecture.drawio.

Before your final scan, do you think every red callout can be traced to either visible node evidence or a documented baseline?

Inspect the complete First Pass page.
Check that the inventory includes every available node.
Check that every node has version, CPU, RAM, NIC, disk, and Ceph entries.
Check that the audit panel lists all eight baseline criteria.
Check that the combined Shared Network has a red Gap callout.
Check that the three-OSD design has a red Gap callout.
Check that every unverified detail is labeled Needs validation.

You should see current-state inventory for every available node. The audit baseline should show three MONs, more than one MGR, one OSD per physical disk, an evenly distributed 12-OSD target, 8 GiB per OSD, no RAID controller before OSD disks, and dedicated 10+ Gbps Ceph traffic.

You should also see red Gap callouts for the combined network plus the three-OSD design. Hardware-specific gaps should appear only where your inventory provides evidence.

Strong work. Your first-pass diagram now exposes its architectural weaknesses without overstating what you know about the live environment.

Does the Audit Look Inconsistent?

Compare the node count under Cluster with the number of inventory sections.
Replace unsupported hardware conclusions with Needs validation.
Keep both mandatory red gaps because the first-pass diagram visibly proves them.

Help me review whether every gap in my Proxmox VE and Ceph diagram is supported by evidence.

Your audit now shows exactly where the first pass falls short. Next, you'll refactor those findings into the Target Architecture page.

Refactor the Target Architecture

Your audited Proxmox VE HCI model now exposes the deliberate shared-network gap. It also shows how a three-OSD sketch can look complete before it meets a production-aware baseline.

This step turns those gaps into a production-aware target through network separation. Dedicated Corosync paths protect latency-sensitive coordination. Dedicated Ceph paths carry storage traffic.

You will distribute storage roles across three target nodes. The future application-container runtime stays inside a QEMU VM.

In this step, get ready to:

Create a target page with four separate network lanes.
Distribute Ceph roles across three target nodes.
Place the future Docker workload inside a QEMU VM backed by Ceph RBD.

Create the target network lanes

The Target Architecture page keeps recommendations separate from the evidence on First Pass. In draw.io, each lane gives one traffic class a visible path.

Switch back to the draw.io tab from earlier.
Click the + below the canvas.
Name the new page Target Architecture.

You now have a separate canvas for the documented target. The audited current state remains unchanged on First Pass.

Add a page note labeled Documented target. Existing hardware requires validation..
Drag four wide rectangles from the left shape panel onto the canvas.
Arrange the rectangles as parallel horizontal lanes.
Label the first lane Corosync: dedicated 1 Gbps, low latency.
Label the second lane Ceph public/client: dedicated 10+ Gbps.
Label the third lane Ceph cluster/internal: 25+ Gbps high-performance target.
Label the fourth lane Guest/Application Network.

Why separate the traffic?

Corosync is sensitive to latency jitter. Its dedicated path keeps storage bursts away from cluster coordination.

The Ceph public/client lane carries RBD-backed virtual disk traffic. The Ceph cluster/internal lane carries replication plus heartbeat traffic.

The guest/application lane carries workload traffic. This keeps application connections separate from cluster coordination.

Add a blank IP field beside every network lane.
Add a blank VLAN field beside every network lane.

You should see four distinct network paths with no assigned IP values. The VLAN fields should also remain blank pending network-owner approval.

Distribute the Ceph roles

Role distribution turns three node blocks into a resilience plan. The target counts must remain clearly separate from your current-state inventory.

Why use a symmetric role layout?

Three MON roles provide the documented target for high availability plus quorum.

A MGR on every node provides redundant manager placement. Four OSD disks per node produce an evenly distributed target of 12.

Each OSD represents one target physical disk. The diagram does not claim that the current nodes already provide those disks.

Drag three equally sized rectangles above the network lanes.
Label the left block Node 1.
Label the center block Node 2.
Label the right block Node 3.
Add Proxmox VE inside every node block.
Place one MON inside every node block.
Place one MGR inside every node block.
Place four disk cylinders labeled OSD inside every node block.

The three blocks now show the symmetric role target. Each node contributes the same monitor count plus manager count plus storage-disk count.

Connect every target node to Corosync: dedicated 1 Gbps, low latency.
Connect every target node to Ceph public/client: dedicated 10+ Gbps.
Connect every target node to Ceph cluster/internal: 25+ Gbps high-performance target.

You should count three MON roles across the page. You should also count three MGR roles.

Each node should contain four OSD disks. The total target should be 12 OSDs.

Connect storage to the workload

The storage boundary completes the target architecture. Ceph RBD provides the virtual disk for the QEMU VM.

The application runtime belongs inside the VM. Docker Engine + Compose App reaches only the guest/application network.

Add a storage block below the target nodes labeled Ceph RBD Pool.
Draw a connector from Node 1 to Ceph RBD Pool.
Draw a connector from Node 2 to Ceph RBD Pool.
Draw a connector from Node 3 to Ceph RBD Pool.
Add a block above the pool labeled QEMU VM.
Place Docker Engine + Compose App inside the QEMU VM.
Draw the QEMU VM virtual-disk connection to Ceph RBD Pool.
Connect the application interface only to Guest/Application Network.

Why put Docker inside a QEMU VM?

Proxmox VE recommends a QEMU virtual machine for application containers that need orchestration or live migration. This keeps the container runtime inside a guest boundary.

Ceph RBD supplies the VM disk path. The guest/application network supplies the workload traffic path.

Before the final check, which two destinations should the QEMU VM use for storage traffic plus application traffic?

Inspect the entire Target Architecture page from the network lanes through the QEMU VM.

You should see four separate network lanes. The IP fields plus VLAN fields should stay blank.

You should see three target nodes with one MON plus one MGR in each. Every node should contain four OSD disks.

The Ceph RBD Pool should connect to all three target nodes. The QEMU VM virtual disk should connect to that pool.

The application interface should connect only to Guest/Application Network. The page note should keep the target separate from current-state evidence.

Can't trace every path?

Count the OSD disks node by node if the total is below 12.
Confirm that the QEMU VM virtual-disk connector ends at Ceph RBD Pool.
Remove any application-interface connection to a Corosync or Ceph lane.

Help me review my target architecture connections.

You closed the hardest architecture gap by making every traffic boundary visible.

Next, you'll record the rationale behind the design. Then you'll publish the complete architecture package as a shareable PDF.

Record Decisions and Publish the Design

Your target page now translates the audited evidence from Proxmox VE into a production-aware design. A reader could still mistake that diagram for an implementation order if the rationale remains undocumented.

This step adds an architecture decision record that separates observations from recommendations. You will publish the draw.io package as an editable source plus a shareable PDF.

In this step, get ready to:

Create an Architecture Decisions page with five structured rows.
Document the evidence, gaps, and next actions behind the target design.
Publish the architecture package in two formats.

Create the architecture decision record

A decision record preserves the reasoning behind a diagram. Its structure helps reviewers trace each recommendation back to evidence from the audited environment.

Click the + below the drawing canvas.
Name the new page Architecture Decisions.

You should see a third page named Architecture Decisions beside First Pass and Target Architecture.

Create a header row with the fields Decision, Reason, Current Evidence, Gap, and Next Action.
Add five blank decision rows beneath the header row.

You should now see one header row above five empty decision rows.

Record evidence, gaps, and next actions

Each row captures one architectural choice. Every field must distinguish facts you observed from recommendations that still need approval or validation.

How should each field work?

The Decision field states the architectural choice.
The Reason field explains why the choice supports the target design.
The Current Evidence field contains only facts from the audited environment.
The Gap field names unresolved requirements or missing evidence.
The Next Action field assigns an owner or a validation activity.

Complete the first row for Ceph as shared HCI storage using the audited First Pass inventory as evidence.
Complete the second row for network separation using the visible NIC inventory as evidence.
Complete the third row for the 12-OSD target using the candidate disk observations as evidence.
Complete the fourth row for placing Docker inside a QEMU VM using the workload placement on Target Architecture.
Complete the fifth row for separating current-state evidence from target-state recommendations.
Enter Unknown for every missing factual value.
Assign an owner or validation action to every Unknown entry.

You should now see five populated decision rows. Every missing fact should have a clear follow-up path.

Save and export the package

The editable source preserves the design history. The PDF turns the three pages into a review copy that can be shared without access to the live environment.

Protect infrastructure details

This review deserves a slow pass because a shareable PDF can travel beyond its original audience.

PDF export sends the diagram to draw.io's server for generation. Draw.io deletes the diagram from its server after returning the PDF.

Credentials, private keys, and public management addresses must stay out of both files.

Review all three pages for credentials, private keys, or public management addresses.
Remove every sensitive value you find.

Your source is now ready for a safe local save.

Click File in the draw.io top menu.
Select Save As.
Save the updated source locally as proxmox-hci-architecture.drawio.

Good progress. Your rationale is now preserved in the editable source.

Click File in the draw.io top menu.
Select Export As.
Select PDF.
Choose All Pages in the export settings.
Leave Include a copy of my diagram enabled.
Click Export.

Microsoft Edge should download proxmox-hci-architecture.pdf to your device.

Why include a copy of the diagram?

The option embeds editable diagram data in the PDF. Your review package keeps a path back to the underlying diagram structure.

Before you open the PDF, which page do you expect to make the boundary between evidence and recommendations clearest?

Open the downloaded proxmox-hci-architecture.pdf.

You should see First Pass, Target Architecture, and Architecture Decisions in the exported package.

Review the text on all three PDF pages for sensitive infrastructure details.

You should find no credentials, private keys, or public management addresses in the PDF.

Missing a page from the PDF?

Return to the export settings in draw.io and confirm that All Pages is selected.
Confirm that the Architecture Decisions page was saved in proxmox-hci-architecture.drawio before exporting again.

Help me check why my exported draw.io PDF is missing one of the three architecture pages.

That is the package complete. Both files now distinguish observed facts from a documented target.

Secret mission

Add a Failure-Domain Overlay

A clean target architecture can still hide shared dependencies. Add a failure-domain review that simulates one unavailable node and exposes external single points of failure using evidence from your environment.

Clean Up Your Resources

Decide whether to keep your resources available, pause your work to return later, or delete the files entirely. This project created local files only, so there are no ongoing costs.

Resources you used:

Editable draw.io source file proxmox-hci-architecture.drawio containing First Pass, Target Architecture, Architecture Decisions, and Failure-Domain Review.
Locally downloaded PDF file proxmox-hci-architecture.pdf containing the original three-page architecture package.

Keep everything running

No action needed. Choose this if you want to maintain the architecture package as infrastructure documentation.

Keep proxmox-hci-architecture.drawio in a controlled documentation location.
Keep proxmox-hci-architecture.pdf as the shareable three-page export.
Use the saved .drawio source when evidence or target assumptions change.
Use the PDF export workflow from earlier if you want a new package that includes Failure-Domain Review.

Pause - I'll come back to this later

Pausing leaves both local files intact. The browser sessions are the only parts to close.

Close the draw.io tab from earlier.
Close the Proxmox VE tab from earlier.
Leave proxmox-hci-architecture.drawio in its current local location.
Leave proxmox-hci-architecture.pdf in its current local location.

Delete - I don't want to use this again

Deleting these files removes your editable source plus the exported package from this Windows device. Your Proxmox VE environment stays unchanged because this project created no infrastructure.

Press the Windows key to open system search.
Type File Explorer into the search field.
Press Enter to open File Explorer.
Select This PC in the sidebar.
Search for proxmox-hci-architecture.drawio by entering the filename in the search field.
Select the matching source file.
Use the delete control in the File Explorer toolbar to move the source file to the Recycle Bin.

The editable source is now in the Windows Recycle Bin. The PDF copy remains in its original location.

Replace the search text with proxmox-hci-architecture.pdf.
Select the matching PDF file.
Use the delete control in the File Explorer toolbar to move the PDF file to the Recycle Bin.

Both project files are now separated from their original locations.

Return to the Windows desktop.
Open Recycle Bin from the desktop.
Search inside the Recycle Bin for proxmox-hci-architecture.drawio.
Permanently delete the matching source file.
Search inside the Recycle Bin for proxmox-hci-architecture.pdf.
Permanently delete the matching PDF file.
Confirm that neither filename appears in the Recycle Bin.

You should no longer find either architecture file on the Windows device. The Proxmox VE cluster remains exactly as it was before this documentation project.

Nice Work!

You did it! Your review-ready architecture package now separates observed Proxmox VE evidence from a production-aware Ceph target.

What you learned:

Built a visible first-pass hyper-converged infrastructure model around one Shared Network. Audited the model against observed node evidence to expose the three-OSD shortfall.
Designed a production-aware target with a dedicated path for Corosync traffic. Separated Ceph public/client traffic from Ceph cluster/internal traffic. Placed the future Docker workload inside a QEMU VM backed by Ceph RBD.
Published an editable draw.io source plus a shareable PDF. Captured assumptions in an architecture decision record. Assigned next actions to unresolved gaps.
Secret Mission: added a failure-domain overlay that simulates one unavailable node. Counted the remaining Ceph roles. Labeled external dependencies using available evidence without claiming untested continuity.

Ready to quiz yourself?