public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>,
	Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] docs: add note for not using remote storages
Date: Tue, 11 Jun 2024 20:05:09 +0200	[thread overview]
Message-ID: <6bbdf56a-a2ee-45d5-9645-2720f19757b2@proxmox.com> (raw)
In-Reply-To: <20240611093046.1092265-1-d.csapak@proxmox.com>

This section is a quite central and important one, so I'm being a bit
more nitpicking with it than other content. NFS boxes are still quite
popular, a blanket recommendation against them quite probably won't
help our cause or reducing noise in our getting help channels.

Dietmar already applied this, so would need a follow-up please.

Am 11/06/2024 um 11:30 schrieb Dominik Csapak:
> such as NFS or SMB. They will not provide the expected performance
> and it's better to recommend against them.

Not so sure about doing recommending against them as a blanket statement,
the "remote" part might adjective is a bit subtle and, e.g., using a local
full flash NVMe storage attached over a 100G link with latency in the µs
surely beats basically any local spinner only storage and probably even
a lot of SATA attached SSD ones.

Also, it can be totally fine to use as second datastore, i.e. in a setup
with a (smaller) datastore backed by (e.g. local) fast storage that is
then periodically synced to a slower remote.

> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
> if we want to discourage users even more, we could also detect it on
> datastore creation and put a warning into the task log

I would avoid that, at least not without actually measuring how the
storage performs (which is probably quite prone to errors, or would
require periodic measurements).

> 
> also if we ever come around to implementing the 'health' page thomas
> wished for, we can put a warning/error there too
> 
>  docs/system-requirements.rst | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/docs/system-requirements.rst b/docs/system-requirements.rst
> index fb920865..17756b7b 100644
> --- a/docs/system-requirements.rst
> +++ b/docs/system-requirements.rst
> @@ -41,6 +41,9 @@ Recommended Server System Requirements
>    * Use only SSDs, for best results
>    * If HDDs are used: Using a metadata cache is highly recommended, for example,
>      add a ZFS :ref:`special device mirror <local_zfs_special_device>`.
> +  * While it's technically possible to use remote storages such as NFS or SMB,

Up-front, I wrote some possible smaller improvements upfront but then
a replacement (see below), but I kept the others 

Would do s/remote storages/remote storage/

(We use "storages" quite a few times already, but if possible keeping it
singular sounds nicer IMO)

> +    the additional latency and overhead drastically reduces performance and it's

s/additional latency and overhead/additional latency overhead/ ?

or "network overhead"

If it'd stay as is, the "reduces" should be changed to "reduce" ("latency and
overhead" is plural).


> +    not recommended to use such a setup.

The last part would be better off with just:

"... and is not recommended"


But I'd rather reword the whole thing to focus more on what the actual issue is,
i.e., not NFS or SMB/CIFS per se, but if the network accessing them is slow.
Maybe something like:

* Avoid using remote storage, like NFS or SMB/CIFS, connected over a slow
  (< 10 Gbps) and/or high latency (> 1 ms) link. Such a storage can
  dramatically reduce performance and may even negatively impact the
  backup source, e.g. by causing IO hangs.

I pulled the numbers in parentheses out of thin air, but IMO they shouldn't be too far
off from 2024 Slow™, no hard feelings on adapting them though.

>  
>  * Redundant Multi-GBit/s network interface cards (NICs)
>  



_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel

  parent reply	other threads:[~2024-06-11 18:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-11  9:30 Dominik Csapak
2024-06-11  9:42 ` [pbs-devel] applied: " Dietmar Maurer
2024-06-11 18:05 ` Thomas Lamprecht [this message]
2024-06-12  6:39   ` [pbs-devel] " Dominik Csapak
2024-06-12 15:40     ` Thomas Lamprecht
2024-06-13  8:02       ` Dominik Csapak
2024-06-17 15:58         ` Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6bbdf56a-a2ee-45d5-9645-2720f19757b2@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal