[doc] 2.1 Hardware

[Martin-Weiss]

2.1 Hardware

https://susedoc.github.io/doc-caasp/master/caasp-deployment/single-html/#_hardware

---

disk space requirements need to be enhanced i.e. for /var/lib/containers (sufficient disk space for images, filesystem btrfs or xfs?, second disk for this space?)

[r0ckarong]

@ereslibre What is the recommended default filesystem type now? If I remember correctly it was XFS but we needed to stick with Btrfs for VMWare. Is this still true?

@Martin-Weiss Can you give some rough details about a real world example that could be used as a sizing example for what you're talking about? These requirements are clearly stated as "minimum" and thus imply they can and should be expanded to whatever the use case entails. We can't really make predictions on how users should set this up. If you have a real-world scenario that we can use, please let me see it.

[Martin-Weiss]

It really depends on the images and image update process that is used. I have seen scenarios where the image used for a container was >6G in size (flat and not layered) and where ever line of code change through CI/CD caused re-distribution of an updated image to all container hosts (workers). This can cause lots of space needed for /var/lib/containers or /var/lib/docker.

Just my one /var/lib/docker has 112 GB at the moment... (wow - I am surprised myself by realizing this at the moment... :-0)

So the number of images, their size and the update / change rate and policy vs. the image cleanup policy in the end defines the space we need. For sure this should not be part of the operating systems file-system.

[Martin-Weiss]

In the docker world we have been using and recommending BTRFS especially for /var/lib/docker - but now with CRI-O this might change to XFS and overlay2 driver instead of BTRFS? But with the default setup we do BTRFS for /var/lib/containers ... so do we stay with BTRFS or switch to XFS and if yes or no - why?

[ereslibre]

In the docker world we have been using and recommending BTRFS especially for /var/lib/docker - but now with CRI-O this might change to XFS and overlay2 driver instead of BTRFS?

I think BTRFS or XFS will work just fine. Our current layout is:

• ISO (autoyast)

  • / is btrfs
  • /var/lib is xfs

• JeOS image (openstack)

  • / is xfs

We have support for both, as for what is the recommended one depending on the driver, @saschagrunert or @cyphar can provide more insight.

[Martin-Weiss]

Why did you split of /var/lib instead of /var/lib/containers?
In AutoYaST it seems that all is going to the same disk and the root FS is smaller than what we recommend for SLES (AFAIK we recommend 50G).. - not sure if I would recommend this AutoYaST setup in production or for physical deployments.

[r0ckarong]

@Martin-Weiss Just so I can change the appropriate parts. Will the 50G minimum recommendation be enough typically for master nodes? Most container changes should happen on the workers, no?

If so I will add some recommendations based on the change rate/number of images consideration.

[Martin-Weiss]

@Martin-Weiss Just so I can change the appropriate parts. Will the 50G minimum recommendation be enough typically for master nodes? Most container changes should happen on the workers, no?

So 50 GB for the OS and 50 GB for /var/lib or /var/lib/containers - yes - I believe this should be sufficient. Probably this can be reduced but for the OS using snapshots with BTRFS we need the space and for the images we might also need less but we need to go through the learning curve..

If so I will add some recommendations based on the change rate/number of images consideration.

Maybe we can just write something like best practice is 50G BTRFS for the OS and 50 GB BTRFS for /var/lib/containers?