computergeek125 @ computergeek125 @lemmy.world

Posts

0

Comments

255

Joined

2 yr. ago

Yeah that's totally fair. I have nearly a kilowatt of real time power draw these days, Rome was not built in a day.

That's the neat part - Ceph can use a full mesh of connections with just a pair of switches and one balance-slb 2-way bond per host. So each host only needs 2 NIC ports (could be on the same NIC, I'm using eno1 and eno2 of my R730's 4-port LOM), and then you plug each of the two ports into one switch (two total for redundancy, in case a switch goes down for maintenance or crash). You just need to make sure the switches have a path to each other at the top.

I think you're asking too much from ZFS. Ceph, Gluster, or some other form of cluster native filesystem (GFS, OCFS, Lustre, etc) would handle all of the replication/writes atomically in the background instead of having replication run as a post processor on top of an existing storage solution.

You specifically mention a gap window - that gap window is not a bug, it's a feature of using a replication timer, even if it's based on an atomic snapshot. The only way to get around that gap is to use different tech. In this case, all of those above options have the ability to replicate data whenever the VM/CT makes a file I/O - and the workload won't get a write acknowledgement until the replication has completed successfully. As far as the workload is concerned, the write just takes a few extra milliseconds compared to pure local storage (which many workloads don't actually care about)

I've personally been working on a project to convert my lab from ESXi vSAN to PVE+Ceph, and conversions like that (even a simpler one like PVE+ZFS to PVE+Ceph would require the target disk to be wiped at some point in the process.

You could try temporarily storing your data on an external hard drive via USB, or if you can get your workloads into a quiet state or maintenance window, you could use the replication you already have and rebuild the disk (but not the PVE OS itself) one node at a time, and restore/migrate the workload to the new Ceph target as it's completed.

On paper, (I have not yet personally tested this), you could even take it a step farther: for all of your VMs that connect to the NFS share for their data, you could replace that NFS container (a single point of failure) with the cluster storage engine itself. There's not a rule I know of that says you can't. That way, your VM data is directly written to the engine at a lower latency than VM -> NFS -> ZFS/Ceph/etc

Yeah it's a bit of a chonk. I don't remember the exact itemization on the power bill and I don't have one in front of me.

My server rack has

• 3x Dell R730
• 1x Dell R720
• 2x Cisco Catalyst 3750x (IP Routing license)
• 2x Netgear M4300-12x12f
• 1x Unifi USW-48-Pro
• 1x USW-Agg
• 3x Framework 11th Gen (future cluster)
• 1x Protectli FE4B

All together that draws.... 0.1 kWh.... in 0.327s.

In real time terms, measured at the UPS, I have a running stable state load of 900-1100w depending on what I have at load. I call it my computationally efficient space heater because it generates more heat than is required for my apartment in winter except for the coldest of days. It has a dedicated 120v 15A circuit

Isn't venmo owned by PayPal for the past 10y?

The average damage on that is 45... Konsi OP

Username checks out

... What?

I wondered if someone would post that second one.

For the first, I think Square Enix got it right - headphones light the right image, but with the bridge between the ear cups flopped back on their head.

Alternatively, you could have headphones like the first but with the drivers in the upper cat ear portion by their actual ears.

OT but am I the only one that noticed the fox's headphones aren't on their ears?

I have five Dell servers in the rack, and another two Dells and three x9? (Atom C2758 8-core if memory serves) Supermicros on the shelf.

I think only one or two of the Dells came with iDRAC Enterprise and all the Supermicros had full licensing. It's absolutely beautiful (once you get done fighting the software updates to purge the Java gremlins).

My three R730s were upgraded to Enterprise as soon as I had budget and a spare line item to do so. Power on/off is great and console+ISO is peak. I love this.

If you're looking at Intel, you might be thinking IME/vPro

IPMI (such as iDRAC on Dell) runs off-processor on a different section of the motherboard typically and is installed on AMD servers as well.

What's the difference between horizontal and vertical integration? (I know a few business words but usually not enough to be intelligent, this is a genuine question of confusion)

What's this label on? I can tell what you're supposed to avoid, I'm just curious why the equipment does that

Or (insert MMO of choice)

Well.... All three of them

It's on APNews too - it's real

• I never said anything about EFI not supporting multi boot. I said that the had to be kept in lockstep during updates. I recognize the term "manual" might have been a bit of a misnomer there, since I included systems where the admin has to take action to enable replication. ESXi (my main hardware OS for now) doesn't even have software RAID for single-server datastores (only vSAN). Windows and Linux both can do it, but its a non-default manual process of splicing the drives together with no apparent automatic replacement mechanism - full manual admin intervention. With a hardware RAID, you just have to plop the new disk in and it splices the drive back into the array automatically (if the drive matches)
  • "EFI doesn't understand (normal) MD RAID" - https://unix.stackexchange.com/a/742072/34724 (2023)
  • (untested) "Using metadata 1.0 (end of disk) to splice EFI partitions together" - https://std.rocks/gnulinux_mdadm_uefi.html
  • (untested) "splicing windows dynamic disks together" - https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/set-up-dynamic-boot-partition-mirroring
• Dell and HPe both have had RAM caching for reads and writes since at least 2011. That's why the controllers have batteries :)
  • also, I said it only had to handle the boot disk. Plus you're ignoring the fact that all modern filesystems will do page caching in the background regardless of the presence of hardware cache. That's not unique to ZFS, Windows and Linux both do it.
• mdadm and hardware RAID offer the same level of block consistency validation to my current understanding- you'd need filesystem-level checksumming no matter what, and as both mdadm and hardware RAID are both filesystem agnostic, they will almost equally support the same filesystem-level features (Synology implements BTRFS on top of mdadm - I saw a small note somewhere that they had their implementation request block rebuild from mdadm if btrfs detected issues, but I have been unable to verify this claim so I do not consider it (yet) as part of my hardware vs md comparison)

Hardware RAID just works, and for many, that's good enough. In more advanced systems, all its got to handle is a boot partition, and if you're doing your job as a sysadmin there's zero important data in there that can't be easily rebuilt or restored.

I never said I didn't use software RAID, I just wanted to add information about hardware RAID controllers. Maybe I'm blind, but I've never seen a good implementation of software RAID for the EFI partition or boot sector. During boot, most systems I've seen will try to always access one partition directly and a second in order, which is bypassing the concept of a RAID, so the two would need to be kept manually in sync during updates.

Because of that, there's one notable place where I won't - I always use hardware RAID for at minimum the boot disk because Dell firmware natively understands everything about it from a detect/boot/replace perspective. Or doesn't see anything at all in a good way. All four of my primary servers have a boot disk on either a Startech RAID card similar to a Dell BOSS or have an array to boot off of directly on the PERC. It's only enough space to store the core OS.

Other than that, at home all my other physical devices are hypervisors (VMware ESXi for now until I can plot a migration), dedicated appliance devices (Synology DSM uses mdadm), or don't have a redundant disks (my firewall - backed up to git, and my NUC Proxmox box, both firewalls and the PVE are all running ZFS for features).

Three of my four ESXi servers run vSAN, which is like Ceph and replaces RAID. Like Ceph and ZFS, it requires using an HBA or passthrough disks for full performance. The last one is my standalone server. Notably, ESXi does not support any software RAID natively that isn't vSAN, so both of the standalone server's arrays are hardware RAID.

When it comes time to replace that Synology it's going to be on TrueNAS