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
next prev 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