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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal