94d1faa9c1
As per https://github.com/minio/console/issues/2539 , the websocket behavior integrated as part of Console 0.22.1 (https://github.com/minio/console/pull/2419) seems to break port-forwarding behavior. There's no easy fix for this. NodePorts are a workaround, but slightly kludgy. Ingress is the better long-term solution, but requires more work. This is a stopgap: - For Operator, point users towards NodePorts if port-forwarding fails - For Tenant Console, simply drop port-forwarding entirely and point only at Ingress/LB Out of scope but in progress is Ingress guidance for Nginx and Traefik so we can close the loop on this.
10 KiB
The following tabs provide examples of installing MinIO onto 64-bit
Linux operating systems using RPM, DEB, or binary. The RPM and DEB
packages automatically install MinIO to the necessary system paths and
create a systemd service file for running MinIO
automatically. MinIO strongly recommends using RPM or DEB installation
routes.
RPM (RHEL)
Use the following commands to download the latest stable MinIO RPM and install it.
wget |minio-rpm| -O minio.rpm
sudo dnf install minio.rpmDEB (Debian/Ubuntu)
Use the following commands to download the latest stable MinIO DEB and install it:
wget |minio-deb| -O minio.deb
sudo dpkg -i minio.debBinary
Use the following commands to download the latest stable MinIO binary
and install it to the system $PATH:
wget https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio
sudo mv minio /usr/local/bin/The following tabs provide examples of updating MinIO onto 64-bit Linux operating systems using RPM, DEB, or binary executable.
For infrastructure managed by tools such as Ansible or Terraform, defer to your internal procedures for updating packages or binaries across multiple managed hosts.
RPM (RHEL)
Use the following commands to download the latest stable MinIO RPM and update the existing installation.
curl |minio-rpm| -O minio.rpm
sudo dnf update minio.rpmDEB (Debian/Ubuntu)
Use the following commands to download the latest stable MinIO DEB and upgrade the existing installation:
curl |minio-deb| -O minio.deb
sudo dpkg -i minio.debBinary
Use the following commands to download the latest stable MinIO binary and overwrite the existing binary:
curl https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio
sudo mv minio /usr/local/bin/Replace /usr/local/bin with the location of the existing
MinIO binary. Run which minio to identify the path if not
already known.
You can validate the upgrade by computing the SHA256
checksum of each binary and ensuring the checksum matches across all
hosts:
shasum -a 256 /usr/local/bin/minioThe output of minio --version <minio server> should also
match across all hosts.
MinIO enables Transport Layer Security (TLS) <minio-tls> 1.2+
automatically upon detecting a valid x.509 certificate
(.crt) and private key (.key) in the MinIO
${HOME}/.minio/certs directory.
For systemd-managed deployments, use the
$HOME directory for the user which runs the MinIO server
process. The provided minio.service file runs the process
as minio-user. The previous step includes instructions for
creating this user with a home directory
/home/minio-user.
- Place TLS certificates into
/home/minio-user/.minio/certs. - If any MinIO server or client uses certificates signed by
an unknown Certificate Authority (self-signed or internal CA), you
must place the CA certs in the
/home/minio-user/.minio/certs/CAson all MinIO hosts in the deployment. MinIO rejects invalid certificates (untrusted, expired, or malformed).
If the minio.service file specifies a different user
account, use the $HOME directory for that account.
Alternatively, specify a custom certificate directory using the minio server --certs-dir
commandline argument. Modify the MINIO_OPTS variable in
/etc/defaults/minio to set this option. The
systemd user which runs the MinIO server process
must have read and listing permissions for the specified
directory.
For more specific guidance on configuring MinIO for TLS, including
multi-domain support via Server Name Indication (SNI), see minio-tls. You can optionally
skip this step to deploy without TLS enabled. MinIO strongly recommends
against non-TLS deployments outside of early development.
Open your browser and access any of the MinIO hostnames at port
:9001 to open the MinIO Console <minio-console> login page. For
example, https://minio1.example.com:9001.
Log in with the MINIO_ROOT_USER and MINIO_ROOT_PASSWORD from
the previous step.
You can use the MinIO Console for general administration tasks like Identity and Access Management, Metrics and Log Monitoring, or Server Configuration. Each MinIO server includes its own embedded MinIO Console.
MinIO strongly recommends direct-attached JBOD (Just a Bunch of Disks)
arrays with XFS-formatted disks for best performance. Using any other
type of backing storage (SAN/NAS, ext4, RAID, LVM) typically results in
a reduction in performance, reliability, predictability, and
consistency.
Ensure all server drives for which you intend MinIO to use are of the
same type (NVMe, SSD, or HDD) with identical capacity (e.g.
12 TB). MinIO does not distinguish drive types and does not
benefit from mixed storage types. Additionally. MinIO limits the size
used per drive to the smallest drive in the deployment. For example, if
the deployment has 15 10TB drives and 1 1TB drive, MinIO limits the
per-drive capacity to 1TB.
MinIO requires using expansion notation {x...y}
to denote a sequential series of drives when creating the new , where
all nodes in the have an identical set of mounted drives. MinIO also
requires that the ordering of physical drives remain constant across
restarts, such that a given mount point always points to the same
formatted drive. MinIO therefore strongly recommends
using /etc/fstab or a similar file-based mount
configuration to ensure that drive ordering cannot change after a
reboot. For example:
$ mkfs.xfs /dev/sdb -L DISK1
$ mkfs.xfs /dev/sdc -L DISK2
$ mkfs.xfs /dev/sdd -L DISK3
$ mkfs.xfs /dev/sde -L DISK4
$ nano /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
LABEL=DISK1 /mnt/disk1 xfs defaults,noatime 0 2
LABEL=DISK2 /mnt/disk2 xfs defaults,noatime 0 2
LABEL=DISK3 /mnt/disk3 xfs defaults,noatime 0 2
LABEL=DISK4 /mnt/disk4 xfs defaults,noatime 0 2You can then specify the entire range of drives using the expansion
notation /mnt/disk{1...4}. If you want to use a specific
subfolder on each drive, specify it as
/mnt/disk{1...4}/minio.
MinIO does not support arbitrary migration of a drive with existing MinIO data to a new mount position, whether intentional or as the result of OS-level behavior.
MinIO strongly recommends direct-attached JBOD (Just a Bunch of Disks)
arrays with XFS-formatted disks for best performance.
- Direct-Attached Storage (DAS) has significant performance and consistency advantages over networked storage (NAS, SAN, NFS).
- Deployments using non-XFS filesystems (ext4, btrfs, zfs) tend to have lower performance while exhibiting unexpected or undesired behavior.
- RAID or similar technologies do not provide additional resilience or availability benefits when used with distributed MinIO deployments, and typically reduce system performance.
Ensure all nodes in the use the same type (NVMe, SSD, or HDD) of
drive with identical capacity (e.g. N TB) . MinIO does not
distinguish drive types and does not benefit from mixed storage types.
Additionally. MinIO limits the size used per drive to the smallest drive
in the deployment. For example, if the deployment has 15 10TB drives and
1 1TB drive, MinIO limits the per-drive capacity to 1TB.
MinIO requires using expansion notation {x...y}
to denote a sequential series of drives when creating the new , where
all nodes in the have an identical set of mounted drives. MinIO also
requires that the ordering of physical drives remain constant across
restarts, such that a given mount point always points to the same
formatted drive. MinIO therefore strongly recommends
using /etc/fstab or a similar file-based mount
configuration to ensure that drive ordering cannot change after a
reboot. For example:
$ mkfs.xfs /dev/sdb -L DISK1
$ mkfs.xfs /dev/sdc -L DISK2
$ mkfs.xfs /dev/sdd -L DISK3
$ mkfs.xfs /dev/sde -L DISK4
$ nano /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
LABEL=DISK1 /mnt/disk1 xfs defaults,noatime 0 2
LABEL=DISK2 /mnt/disk2 xfs defaults,noatime 0 2
LABEL=DISK3 /mnt/disk3 xfs defaults,noatime 0 2
LABEL=DISK4 /mnt/disk4 xfs defaults,noatime 0 2You can then specify the entire range of drives using the expansion
notation /mnt/disk{1...4}. If you want to use a specific
subfolder on each drive, specify it as
/mnt/disk{1...4}/minio.
MinIO does not support arbitrary migration of a drive with existing MinIO data to a new mount position, whether intentional or as the result of OS-level behavior.
MinIO strongly recommends restarting all nodes simultaneously. MinIO operations are atomic and strictly consistent. As such the restart procedure is non-disruptive to applications and ongoing operations.
Do not perform "rolling" (e.g. one node at a time) restarts.