Computer problems are a fact of life, and sometimes the fix is as simple as just turning it off and turning it back on again, but other times it's not.

And when the system you're talking about is running an air traffic control system, controlling a bunch of ATMs, or say routing 911 calls, keeping them up and running can be a matter of life and death.

Now, the stakes aren't nearly as high for us, but this server here runs multiple apps that we rely on every day, accelerates our game downloads with Steam caching, and it runs our DNS.

If that service goes down, it breaks literally everyone in the company's internet, which my boss informs me isn't great.

So how do we make it more reliable? It's already a server, we build more servers.

And what's really cool about this is everything we're about to show you, courtesy of Intel, who sponsored this video and sent over their new Emerald Rapids Xeon CPUs, can be done on nearly any computer, even your dad's old Dell, that is as long as you have more than one.

So if one leaves for cigarettes, we can still play catch.

More than one Dell, not more than one dad. Oh well, anyways, I'm done, you want to check this out?

Yeah, let's have a look. You got your lovely cat picture, your crab rave on that computer. M watch this like I can yeah, I can interact with this just just give it a second.

Okay, it's it's going hey now it's on this computer and like no bamboozle here look watch whoa buddy watch watch watch boom unplugged I can just completely interact with this as I normally would.

So what's going on here? What you guys just saw was the programs, the lovely drawing, the entire operating system just teleporting from the computer over here to the one over here, no trickery.

This is possible thanks to the magic of virtualization. We've talked about it before, but if you're not familiar, virtualization allows you to slice up a single machine into multiple less powerful virtual machines, and this setup leverages that technology to allow us to move these virtual machines between multiple physical computers.

That way, if one breaks, another one can immediately take its place. And the best part is that while this all sounds super fancy, all the software we're using is both open source and free, and we're going to show you guys how the setup works in a little bit.

First, I want to take a look at the servers we're going to be using for our setup.

Gigabyte sent over four of their R163 SG2 AAC1 servers. These are bare bones, so we're going to have to add a few of our own parts, but we should be able to build this in what, like 5 minutes?

We're going to add some of our own parts, starting with a pair of Patriot 480 gig SATA SSDs that will function as a mirrored boot drive.

This kind of per machine redundancy isn't strictly speaking necessary because we could lose an entire machine in our configuration without having any issues, but having them in pairs makes our lives easier in the future potentially, since if one of them fails, we can just replace it and then rebuild it from the other one.

Then on the other side of the machine, we're installing two of these Kioxia CD6 7 TB drives for fast bulk storage.

That leaves us six more SATA bays to do nothing with and two more NVMe bays for potential future expansion. Moving back, let's get our CPU installed.

We're using a Xeon Platinum 8562Y+ in each node. These were graciously provided by Intel, and with 32 cores, 64 threads, and 4.1 GHz max turbo clock speeds, these are going to give us a ton of compute to share between our virtual machines, all at a modest 300 watt TDP.

We're going to have it and the rest of the parts linked in the video description.

Now, I've never installed in this socket before, so good luck me. Step one is to install the carrier on the CPU, and you can tell which one of the three you're supposed to use by the little marking right there on the CPU IHS.

Line up our little golden triangle with our gigantic, gargantuan hole in the whole thing.

Triangle. Oh, this is adorable. It's got a cute little arm so you can break the thermal paste seal with the cooler so you can get the cooler and the CPU separated more easily.

Speaking of thermal paste, we're going to be using a Honeywell PTM 7950 pad available at LTTstore.com. This stuff is absolutely perfect for a server install because it lasts not forever, but for a very, very, very long time without maintenance.

Now you might think, okay, go ahead, put it onto the CPU socket.

You'd be wrong. Instead, I'm going to install it onto the cooler. I'm going to know how to do that in a sec.

So arrow and arrow. So maybe, ah, ah, ah, hey, there we go. Damn, look at that vapor chamber. Love me a vapor chamber. Okay.

We're going to make sure all these are clicked into place. Look for our little arrow here, line that up with the arrow on the socket and make sure that the locks are in their unlocked position, then we should be able to just, that's it, it's locked.

Oh, that's it. Okay, next comes something you don't see me do very often, and that is use a screwdriver other than the LTT screwdriver, and that's because these need to be torqued to a specific value, that is 6.9 inch lbs.

Nice. It's so cool to think that if I was doing this, you know, performing maintenance on the server or upgrading a bad RAM stick, our entire operation could be chugging along as if nothing happened.

Speaking of RAM, we've gone with four 96 gig Micron 5600 megatransfer per second registered ECC DIMMs. That's a somewhat unconventional choice because, especially in a server, giving up half of the memory channels means that we will be giving up some performance, but we don't really need all of the performance for now, and 384 gigs is a ton of capacity for our needs at the moment, and of course, if anything changes, we can always add more without any downtime to our services.

The only thing that's really important here then is making sure that we install our sticks in the correct slots, which is not always super intuitive, so make sure to consult your manual.

We don't need a GPU for now, though we could add one in the future.

So that means all that's really left is these Nvidia ConnectX-6 cards. Now 100 Gig networking might seem a bit overkill, but because our setup uses high-speed drives in four servers and we want to be able to withstand two server failures, anytime we're writing data, it has to be simultaneously written to the drives on at least three machines.

That ensures we have three up-to-date copies in the event of an unexpected failure.

Now, if you were doing this at home, you obviously wouldn't want to spend this kind of money, but the good news is that you can do this with as few as two machines.

And if you're not trying to run a high-speed caching server for 100 people, 10 or 25 gig cards are available for a fraction of the price, and you can connect them directly to each other without an expensive switch.

I mean, even one gig could work for light applications like ensuring that your home automation system never goes down.

Enough chitchat, though, let's get on with the demo and show you what happens if one of these things goes to heaven in a live environment, but not before we get them in the rack and set up specifically here in the lab server room.

Because if you didn't notice earlier, the studio server room is kind of running out of space, at least until these machines are up and running and we can take the machine they're replacing out.

Let's go grab the service. Unfortunately, the rest of the machines are now magically built off of camera and we can just slide them in.

What the hell is going on? Oh, there we go. Beautiful. These Gigabyte chassis come with nice toolless rails, so installing these in our nice ginormous Hammond rack should be pretty easy.

Yeah, look at that. It's getting close. I can taste it.

We just need networking. Like we mentioned before, 100 gig, but what we didn't mention before is that each is getting two of them, specifically one to each of the network switches in the rack.

That way, if one of those switches has a problem, the servers will stay up and we even get an added bonus because some fancy Dell magic called VT, we get the throughput of both of these cables, so 200 gig to each surface, pretty sick.

All that's left then is power and like any other good server, IPMI, which is a management interface and allows us to control the machines even if they're not working.

They have like a hardware problem, we can still access them, we can turn them on, turn them off. It's kind of magic.

If you have a server that doesn't have IPMI, I don't know, I don't even know if that's a server really.

There are two main elements to making this setup work: clustering the hypervisor, which controls our virtual machines, and clustering the storage, which you can skip if you have existing network storage you want to use instead.

If you're not not interested in how to set this up, you can skip ahead to here to see what it's like when it's up and running.

This isn't going to be a perfect step-by-step guide, but with the documentation you can find down in the description, you should be able to replicate this setup pretty easily.

Starting with networking, we added both of our 100 Gig ports to a bond, created a bridge, and then added a VLAN for three different networks: one for our VMs to use, one for cluster communication, and one for the storage.

They can all technically run on the same network, but the cluster needs low latency and the storage ideally uses jumbo frames, so splitting it up like this is best practice.

You'll also need to add each node's cluster network IP address to the host file on each node.

With the networking up and running, enable the no subscription repo and disable the Enterprise repo. It's not recommended by the Proxmox team, for production, they want you to pay for the Enterprise repo, which is a bit more stable, but the free one is totally fine for a home setup.

Run any pending updates before proceeding. Then make sure you have a reliable and ideally local time server configured on each of your individual servers, as the clustering software wants the time very closely in sync to stay happy.

With that out of the way, we can set up our cluster, which handles syncing the configuration and management of any virtual machines between our physical machines, and it also orchestrates migrating or restoring them when a machine goes down.

Creating the cluster just takes actually a few clicks, but you might want to consider the size of your setup before you continue. That's because in order to make sure everything stays in sync in case of an issue with a machine, you need the majority of servers online and available to be able to say, hey, I see that one's offline, but you know, we're we're still good.

They call this Quorum. If you have an even number of machines, let's say four, like we do, and each server gets the default single say or vote, the minimum possible majority is then three servers, so that means we can only withstand one going down, which is the same amount of redundancy you'd get if you had three machines, 'cause you can only lose one to have two.

If you only have two computers, then you only ever have a majority when both are online, which obviously doesn't work, that's not safe.

But you can screw it around this by adding a third machine, like say a Raspberry Pi to be a tiebreaker, but that's kind of beyond the scope of this video.

Once you're ready, select the cluster network in the creation menu, and then join the other machines to the cluster.

Once they're in, you should be able to see them in the web GUI of any of the machines. Now, on to clustering our storage.

By default, Proxmox is very heavily integrated with SEF, an open source distributed storage system that's pretty easy to set up and maintain.

With that in mind, newbies should start with Seth, and you can follow the great tutorial on their Wiki, but it isn't the most performant in a small cluster like this, so we're going to be using something called Linode with DRBD, or distributed replicated block device, another open source storage system.

It requires a bit more manual configuration, but they do have a purpose-built tutorial for Proxmox and host the files for free with an optional paid Enterprise version that operates on a similar model as Proxmox itself.

Unlike SEF, it doesn't handle its own storage devices, so we mirrored our two Kioxia SSDs with ZFS first and then pointed Lin store to that.

Once it's installed and configured, then you can add the clustered storage to Proxmox, create a virtual machine with that storage, and it'll automatically be replicated in real time to the number of other nodes you specify.

And if you happen to migrate a VM to a server that doesn't have a copy on it, it'll automatically stream the data over the network from one of those nodes in what they call dis list mode, but let's just try it.

Hey, pretty nice, right? Looking good. It's like even cable managed. I know, right? So 200 gig on each of them.

Nice. Who are you people and what have you done with our infer team? I made one small adjustment just for you.

Look at the drives. They're in the same spot. No, they're not. The top one's different. I hate you so much. Why?

would you do that but more importantly does it work? Uh, yeah, obviously. Okay, well here's your Windows desktop. Obviously, he says, what editor? A super cut of things not working here.

Please, Jake, we have a leak. Oh God, one failure. You just downgraded my Wi-Fi. Four drives aren't working.

Did you actually break it? Anyways, you see our Windows, right? Yeah, our Windows is running right now on number four, which is the bottom server.

Yes. Now, obviously, remoting into the machine over Wi-Fi. Okay, the video playback's a little bit choppy. That's not going to affect the type of workload we would normally be running on something like this, like a DNS server or like, are we finally doing Active Directory?

Not today, but we can now. But this is the kind of setup that you want for something like AD live, playing the video. Let's migrate to number one, which is the top one.

The process will be a little bit faster, but basically what it's doing is copying the memory, like the RAM, what's actually in memory.

And then once it's done most of it, it pauses the operating system for a split second, copies the last tiny little bit and boom.

That is so cool. You're exactly where you were before because the storage is already there, right? So in terms of actual downtime, like interruption to that experience, 17 seconds, no, 270 milliseconds.

Oh, I thought you were pointing the other. No, 17 seconds is that whole process.

But oh yeah, yeah, well, that's kind of downtime, I guess. No, cuz that if there was somebody using this like as a virtual desktop for instance, they would see like a quarter of a second blink and otherwise like nothing changed.

I wanted to show a more realistic to us demo. Sure, come hither.

here's a Plex server, we've got some videos on it, and this is on server number one. Okay, let's play a video now.

We go and move our Plex server to a different machine, so it's copying the RAM at 2.5 gigabytes a second, so it's like 2.8 gigabytes a second, that's pretty good.

We haven't done any actual, oh, it's already done and no interruption because video playback, like many other applications, uses buffers to hide small interruptions in the service.

In this case, downloading the video in small chunks a little bit at a time, yeah, roughly 10-second chunks it looks like here, which is plenty to cover that 146 milliseconds of downtime.

Wow. You want to try Steam download with LAN cache? I mean, we should. Yeah, why not? Yep, we're CPU bottleneck for sure, using, you know, 80 to 90% of a 24 core Threadripper.

But I realized I made a little bit of an oopsy here.

Look, you can see the CPU usage. We're using % of our eight CPUs that I assigned to this Steam cache. We can see our network traffic's going up, sick.

Except I made this as a container, not a VM, and the thing with containers, they're great, they're a little bit lighter weight, better performance, but they run within the kernel of the main system.

It'll shut down that container and then just reboot on the other machine, right, which means it's fine, but there will be a longer downtime delay, but way less than, hey, is that thing working?

Oh, I think the internet is not working. Somebody should go look at that. Yeah, trying to figure out what's going on, fixing the machine, getting the machine back going so cool.

You're talking about the matter of a couple minutes maybe. Yeah. Now for the most impressive demo yet, the unexpected migration.

Which one am I yanking? Okay, so number one has three VMs on it. They're all in the high availability Jake's chain.

Ah, what means? Oh, I get it. Okay, sorry. Which one? I wasn't even listening to number one, number one and we'll see how how fast it does.

I Built a PC that CAN’T Fail… and You Can Too!

Linus Tech Tips is a passionate team of "professionally curious" experts in consumer technology and video production who aim to educate and entertain.


Linus Tech Tips

컴퓨터 문제는 피할 수 없는 현실이며, **중요한 시스템의 경우 안정적인 운영이 생명과 직결될 수 있습니다**. Linus Tech Tips는 일상적으로 사용하는 여러 앱과 서비스를 실행하는 서버의 안정성을 높이는 방법을 모색합니다. 이 서버는 Steam 캐싱을 통해 게임 다운로드 속도를 높이고 DNS를 실행하여 회사 전체의 인터넷 연결을 유지하는 데 중요한 역할을 합니다. 서버가 다운되면 회사 전체의 인터넷이 마비되므로, **서버의 안정성을 확보하는 것이 매우 중요합니다**.

Linus Tech Tips는 Intel의 후원을 받아 새로운 Emerald Rapids Xeon CPU를 사용하여 서버 클러스터를 구축합니다. 핵심은 **가상화 기술을 활용하여 하나의 물리적 머신을 여러 개의 가상 머신으로 나누고**, 이 가상 머신들을 여러 물리적 컴퓨터 간에 이동시키는 것입니다. 이렇게 하면 **하나의 서버가 고장나더라도 다른 서버가 즉시 대체하여 서비스를 계속 유지할 수 있습니다**.

Gigabyte에서 제공한 R163 SG2 AAC1 서버 네 대를 사용하여 클러스터를 구축합니다. Patriot SATA SSD를 미러링된 부트 드라이브로 사용하고, Kokia CD6 7TB SSD를 고속 대용량 스토리지를 위해 설치합니다. 각 노드에는 Xeon Platinum 8562Y+ CPU가 탑재되어 **32개의 코어와 64개의 스레드를 통해 가상 머신에 충분한 컴퓨팅 성능을 제공합니다**.

네트워킹에는 Nvidia ConnectX-6 카드를 사용하여 100Gbps 네트워크를 구성합니다. 데이터는 최소 세 대의 머신에 동시에 기록되어 **두 대의 서버가 고장나더라도 데이터 손실을 방지합니다**. 가정에서는 더 저렴한 10Gbps 또는 25Gbps 카드를 사용할 수 있으며, **홈 오토메이션 시스템과 같이 가벼운 애플리케이션의 경우 1Gbps로도 충분합니다**.

클러스터링 설정에는 하이퍼바이저 클러스터링과 스토리지 클러스터링의 두 가지 주요 요소가 있습니다. Proxmox는 Ceph와 같은 오픈 소스 분산 스토리지 시스템과 통합되어 있지만, **Linus Tech Tips는 더 나은 성능을 위해 Linore와 DRBD를 사용합니다**. Linore는 ZFS로 미러링된 SSD에 연결되어 데이터를 여러 노드에 실시간으로 복제합니다.

데모에서는 Windows 데스크톱, Plex 서버, Steam 다운로드 캐시를 가상 머신으로 실행하고, **서버 간에 마이그레이션하는 과정을 보여줍니다**. 마이그레이션 중에도 서비스 중단은 거의 없으며, **예상치 못한 서버 장애 시에도 가상 머신이 자동으로 다른 서버로 이동하여 서비스를 계속 제공합니다**.

Linus Tech Tips는 이 아키텍처가 반드시 최신 서버 기술에서만 실행될 필요는 없다고 강조합니다. **중고 8세대 Intel Core 프로세서와 저렴한 DDR4 메모리를 사용하여 가정에서도 비슷한 시스템을 구축할 수 있습니다**. 비즈니스 환경에서는 Intel Emerald Rapids 및 Xeon 제품군을 고려할 수 있습니다.

결론적으로, 서버 클러스터링은 **비용 효율적인 방법으로 서버 안정성을 높이고 서비스 중단을 최소화할 수 있는 효과적인 솔루션입니다**. 가정이나 비즈니스 환경 모두에서 활용할 수 있으며, **가상화 기술과 오픈 소스 소프트웨어를 통해 더욱 쉽게 구축할 수 있습니다**.

컴퓨터 문제는 일상다반사이고, 때로는 그냥 껐다 켜는 것만으로도 해결되지만, 그렇지 않은 경우도 있습니다.

만약 여러분이 이야기하는 시스템이 항공 교통 관제 시스템을 운영하거나, ATM을 제어하거나, 911 통화를 연결하는 시스템이라면, 시스템을 계속 가동하는 것은 생사의 문제가 될 수 있습니다.

저희에게는 그만큼 위험 부담이 크진 않지만, 이 서버는 저희가 매일 사용하는 여러 앱을 실행하고, 스팀 캐싱으로 게임 다운로드 속도를 높이고, DNS를 실행합니다.

이 서비스가 중단되면 회사 내 모든 사람의 인터넷이 끊기는데, 상사 말로는 심각한 문제라고 합니다.

그렇다면 어떻게 해야 더 안정적으로 만들 수 있을까요? 이미 서버가 있으니 서버를 더 구축하면 됩니다.

정말 멋진 점은 인텔의 지원을 받아 보여드릴 이 모든 것이 거의 모든 컴퓨터에서 가능하다는 것입니다. 인텔에서 이번 영상에 스폰서로 참여하여 새로운 에메랄드 래피즈 제온 CPU를 보내주셨는데, 아버지의 구형 Dell 컴퓨터에서도 2대 이상만 있으면 가능합니다.

그러니 하나가 담배를 사러 나가도 캐치볼을 할 수 있습니다.

Dell이 두 대 이상이어야지, 아버지가 두 분 이상이라는 뜻은 아닙니다. 어쨌든, 저는 끝났으니 한번 확인해 보시겠어요?

네, 한번 보죠. 여기 고양이 사진이 있고, 저 컴퓨터에는 크랩 레이브가 있네요. 잠깐만요. 네, 상호 작용할 수 있습니다. 잠깐만 기다려 보세요.

좋아요. 이제 이 컴퓨터에 떴네요. 속임수는 없습니다. 보세요. 짠! 플러그를 뽑아도 평소처럼 완전히 상호 작용할 수 있습니다.

여기서 무슨 일이 일어나고 있는 거죠? 여러분이 보신 것은 프로그램, 멋진 그림, 전체 운영 체제가 이 컴퓨터에서 저 컴퓨터로 순간 이동하는 모습입니다. 속임수는 없습니다.

이는 가상화 기술 덕분에 가능합니다. 이전에도 말씀드렸지만, 익숙하지 않으신 분들을 위해 설명드리자면, 가상화 기술을 사용하면 단일 머신을 여러 개의 성능이 낮은 가상 머신으로 나눌 수 있으며, 이 설정은 해당 기술을 활용하여 이러한 가상 머신을 여러 물리적 컴퓨터 간에 이동할 수 있도록 합니다.

그렇게 하면 하나가 고장나더라도 다른 하나가 즉시 대체할 수 있습니다. 가장 좋은 점은 이 모든 것이 매우 멋지게 들리지만, 우리가 사용하는 모든 소프트웨어는 오픈 소스이고 무료이며, 잠시 후에 설정이 어떻게 작동하는지 보여드릴 것입니다.

먼저, 설정에 사용할 서버를 살펴보겠습니다.

기가바이트에서 R163 SG2 AAC1 서버 4대를 보냈습니다. 이것들은 베어본이므로 몇 가지 부품을 추가해야 하지만, 5분 안에 조립할 수 있을 겁니다.

미러링된 부팅 드라이브로 작동할 Patriot 480GB SATA SSD 한 쌍을 시작으로 몇 가지 부품을 추가할 것입니다.

이러한 종류의 시스템별 이중화는 엄밀히 말하면 필요하지 않습니다. 구성에서 전체 시스템을 잃어도 아무런 문제가 없기 때문입니다. 하지만 쌍으로 구성하면 앞으로 훨씬 더 편리해집니다. 하나가 고장나면 교체한 다음 다른 하나에서 다시 빌드할 수 있기 때문입니다.

그런 다음 시스템의 다른 쪽에는 빠른 대용량 스토리지를 위해 Kioxia CD6 7TB 드라이브 두 개를 설치합니다.

그러면 SATA 베이 6개와 NVMe 베이 2개가 더 남아 잠재적인 향후 확장을 위해 아무것도 하지 않게 됩니다. 뒤로 돌아가서 CPU를 설치해 보겠습니다.

각 노드에는 Xeon Platinum 8562Y+를 사용하고 있습니다. 이것은 Intel에서 제공해 주셨고, 32개의 코어, 64개의 스레드, 4.1GHz 최대 터보 클럭 속도로, 모두 300와트의 TDP로 가상 머신 간에 공유할 수 있는 많은 컴퓨팅 성능을 제공할 것입니다.

비디오 설명에 링크된 나머지 부품도 있을 것입니다.

이제 이 소켓에 설치해 본 적이 없으니 행운을 빌어 주세요. 1단계는 CPU에 캐리어를 설치하는 것입니다. CPU IHS에 있는 작은 표시로 세 개 중 어느 것을 사용해야 하는지 알 수 있습니다.

작은 황금색 삼각형을 전체에 있는 거대한 구멍과 정렬합니다.

삼각형. 오, 귀엽네요. 쿨러와 CPU를 더 쉽게 분리할 수 있도록 쿨러로 써멀 페이스트 실을 깨뜨릴 수 있는 귀여운 작은 팔이 있습니다.

써멀 페이스트 얘기가 나와서 말인데, LTTstore.com에서 판매하는 Honeywell PTM 7950 패드를 사용할 겁니다. 이 제품은 서버 설치에 완벽합니다. 영원히 지속되지는 않지만 유지 보수 없이 아주 오랫동안 사용할 수 있기 때문입니다.

이제 여러분은 'CPU 소켓에 바로 설치하겠지'라고 생각할 수 있습니다.

틀렸습니다. 대신 쿨러에 설치할 겁니다. 곧 방법을 알려드리겠습니다.

화살표와 화살표. 아, 아, 아, 됐다. 저 증기 챔버 좀 봐. 증기 챔버 너무 좋아. 좋아요.

모두 제자리에 있는지 확인하겠습니다. 여기 작은 화살표가 있는데, 소켓의 화살표와 맞추고 잠금 장치가 해제 위치에 있는지 확인한 다음, 잠그면 됩니다. 잠겼습니다.

됐습니다. 다음은 제가 자주 하지 않는 일인데, LTT 드라이버가 아닌 다른 드라이버를 사용하는 겁니다. 특정 값으로 조여야 하기 때문인데, 6.9인치 파운드입니다.

좋아요. 제가 서버 유지 보수를 하거나 불량 RAM 스틱을 업그레이드하는 동안에도 아무 일도 없었던 것처럼 전체 운영이 계속 진행될 수 있다는 생각을 하니 정말 멋지네요.

RAM 얘기가 나와서 말인데, Micron 5600 메가트랜스퍼/초 등록 ECC DIMM 96GB 4개를 사용했습니다. 특히 서버에서는 메모리 채널의 절반을 포기하면 성능이 저하될 수 있기 때문에 다소 파격적인 선택입니다. 하지만 지금은 모든 성능이 필요한 것은 아니고, 384GB는 현재 필요에 비해 엄청난 용량입니다. 물론 상황이 바뀌면 서비스 중단 없이 언제든지 더 추가할 수 있습니다.

여기서 정말 중요한 것은 스틱을 올바른 슬롯에 설치하는 것입니다. 항상 직관적이지 않으므로 설명서를 참조하십시오.

지금은 GPU가 필요 없지만 나중에 추가할 수 있습니다.

자, 결국 남은 건 이 Nvidia ConnectX-6 카드뿐이네요. 100기가비트 네트워킹은 약간 과하게 보일 수도 있지만, 저희 설정은 4개의 서버에서 고속 드라이브를 사용하고 서버 두 대가 고장나도 견딜 수 있기를 원하기 때문에 데이터를 쓸 때마다 최소 3대 이상의 장치에 동시에 기록해야 합니다.

그래야 예상치 못한 오류가 발생했을 때 최신 복사본 3개를 확보할 수 있습니다.

집에서 이렇게 하려면 당연히 이런 데 돈을 쓰고 싶지 않겠지만, 좋은 소식은 기계 두 대만으로도 가능하다는 것입니다.

그리고 100명에게 고속 캐싱 서버를 실행하려는 것이 아니라면 10기가비트 또는 25기가비트 카드를 더 저렴한 가격에 구입할 수 있으며, 비싼 스위치 없이도 서로 직접 연결할 수 있습니다.

제 말은, 홈 자동화 시스템이 절대 다운되지 않도록 하는 것과 같은 가벼운 애플리케이션의 경우 1기가비트만으로도 충분할 수 있다는 것입니다.

잡담은 이쯤하고, 데모를 통해 이 중 하나가 라이브 환경에서 어떻게 되는지 보여드리겠습니다. 하지만 그 전에 랙에 넣고 특히 여기 랩 서버실에 설치해야 합니다.

아까 눈치채셨는지 모르겠지만, 스튜디오 서버실은 공간이 부족합니다. 적어도 이 장비들이 가동되고 교체할 장비를 꺼낼 수 있을 때까지는요.

서버를 가져가겠습니다. 안타깝게도 나머지 장비들은 카메라 밖에서 마법처럼 제작되었고 그냥 밀어 넣기만 하면 됩니다.

대체 무슨 일이야? 아, 됐네요. 좋습니다. 이 기가바이트 섀시는 훌륭한 도구 필요 없는 레일과 함께 제공되므로 멋진 초대형 해먼드 랙에 설치하는 것이 매우 쉬울 것입니다.

네, 저것 좀 보세요. 거의 다 왔습니다. 거의 다 왔어요.

네트워킹이 필요합니다. 앞에서 언급했듯이 100기가비트이지만, 전에 언급하지 않았던 것은 각각 2개씩, 특히 랙에 있는 네트워크 스위치 각각에 하나씩 연결된다는 것입니다.

이렇게 하면 스위치 중 하나에 문제가 발생하더라도 서버가 계속 작동하고, 델의 멋진 VT라는 마법 덕분에 추가 보너스도 얻을 수 있습니다. 즉, 각 표면에 200기가비트의 처리량을 제공하므로 매우 좋습니다.

남은 건 전원 공급뿐이고, 다른 좋은 서버와 마찬가지로 IPMI가 있습니다. IPMI는 관리 인터페이스로, 장비가 작동하지 않더라도 장비를 제어할 수 있게 해줍니다.

하드웨어에 문제가 생겨도 액세스해서 켜고 끌 수 있습니다. 거의 마법이죠.

IPMI가 없는 서버는 글쎄요, 그게 서버인지조차 모르겠습니다.

이 설정을 작동시키는 데는 두 가지 주요 요소가 있습니다. 가상 머신을 제어하는 하이퍼바이저 클러스터링과 스토리지를 클러스터링하는 것입니다. 기존 네트워크 스토리지를 대신 사용하려면 스토리지는 건너뛸 수 있습니다.

설정 방법에 관심이 없다면 여기로 건너뛰어 실행 중일 때 어떤지 확인할 수 있습니다.

이것은 완벽한 단계별 가이드가 아니지만, 설명에서 찾을 수 있는 설명서를 통해 이 설정을 꽤 쉽게 복제할 수 있을 것입니다.

네트워킹부터 시작하여 100기가비트 포트 두 개를 모두 본딩에 추가하고 브리지를 만든 다음 VM에서 사용할 네트워크, 클러스터 통신용 네트워크, 스토리지용 네트워크의 세 가지 네트워크에 대한 VLAN을 추가했습니다.

기술적으로는 모두 동일한 네트워크에서 실행할 수 있지만 클러스터는 짧은 지연 시간이 필요하고 스토리지는 가급적 점보 프레임을 사용하므로 이처럼 분할하는 것이 가장 좋습니다.

각 노드의 클러스터 네트워크 IP 주소를 각 노드의 호스트 파일에 추가해야 합니다.

네트워킹이 작동되면 구독 없음 리포지토리를 활성화하고 엔터프라이즈 리포지토리를 비활성화합니다. Proxmox 팀에서는 프로덕션 환경에 권장하지 않습니다. 좀 더 안정적인 엔터프라이즈 리포지토리에 대해 비용을 지불하기를 원하지만 무료 리포지토리도 홈 설정에는 완전히 적합합니다.

계속하기 전에 보류 중인 업데이트를 실행합니다. 그런 다음 각 개별 서버에 안정적이고 가급적 로컬 시간 서버가 구성되어 있는지 확인합니다. 클러스터링 소프트웨어는 원활하게 작동하려면 시간이 매우 정확하게 동기화되기를 원하기 때문입니다.

이제 클러스터를 설정할 수 있습니다. 클러스터는 물리적 머신 간의 모든 가상 머신에 대한 구성 및 관리를 동기화하고 머신이 다운되면 마이그레이션 또는 복원을 오케스트레이션합니다.

클러스터를 만드는 데는 실제로 몇 번의 클릭만 필요하지만, 계속하기 전에 설정 크기를 고려해야 할 수도 있습니다. 왜냐하면 머신에 문제가 발생할 경우 모든 것이 동기화되도록 하려면, 대부분의 서버가 온라인 상태로 유지되어야 하고, '저 서버가 오프라인인 것을 알지만, 우리는 괜찮아'라고 말할 수 있어야 하기 때문입니다.

그들은 이것을 쿼럼이라고 부릅니다. 만약 여러분이 우리처럼 4대와 같이 짝수 대의 머신을 가지고 있고, 각 서버가 기본적으로 단일 발언권 또는 투표권을 갖는다면, 최소한 가능한 다수는 3대의 서버입니다. 즉, 우리는 단 한 대의 서버만 다운되는 것을 감당할 수 있는데, 이는 3대의 머신을 가지고 있을 때 얻을 수 있는 것과 같은 양의 이중화입니다. 왜냐하면 두 대를 가지려면 한 대만 잃을 수 있기 때문입니다.

만약 여러분이 단 두 대의 컴퓨터만 가지고 있다면, 둘 다 온라인 상태일 때만 다수를 가질 수 있는데, 이는 분명히 작동하지 않습니다. 안전하지 않습니다.

하지만 라즈베리 파이와 같은 세 번째 머신을 추가하여 무승부를 깨는 방식으로 이를 해결할 수 있지만, 이는 이 비디오의 범위를 벗어납니다.

준비가 되면 생성 메뉴에서 클러스터 네트워크를 선택한 다음 다른 머신을 클러스터에 가입시키십시오.

일단 연결되면, 어떤 머신의 웹 GUI에서도 볼 수 있어야 합니다. 이제 스토리지 클러스터링으로 넘어갑시다.

기본적으로 Proxmox는 설정 및 유지 관리가 매우 쉬운 오픈 소스 분산 스토리지 시스템인 SEF와 매우 긴밀하게 통합되어 있습니다.

이 점을 염두에 두고, 초보자는 Seth로 시작해야 하며, 해당 위키에서 훌륭한 튜토리얼을 따라갈 수 있습니다. 하지만 이것은 이와 같은 작은 클러스터에서는 성능이 가장 좋지 않으므로, 우리는 DRBD 또는 분산 복제 블록 장치가 있는 Linode라는 것을 사용할 것입니다. 또 다른 오픈 소스 스토리지 시스템입니다.

약간 더 수동 구성이 필요하지만, Proxmox용으로 특별히 제작된 튜토리얼이 있으며, Proxmox 자체와 유사한 모델로 작동하는 선택적 유료 엔터프라이즈 버전으로 파일을 무료로 호스팅합니다.

SEF와 달리 자체 스토리지 장치를 처리하지 않으므로 먼저 두 개의 Kioxia SSD를 ZFS로 미러링한 다음 Lin store를 가리켰습니다.

일단 설치 및 구성이 완료되면 클러스터 스토리지를 Proxmox에 추가하고, 해당 스토리지를 사용하여 가상 머신을 만들 수 있습니다. 그러면 지정한 다른 노드 수만큼 실시간으로 자동 복제됩니다.

VM을 복사본이 없는 서버로 마이그레이션하는 경우, 디스 리스트 모드라고 하는 방식으로 네트워크를 통해 해당 노드 중 하나에서 자동으로 데이터를 스트리밍합니다. 하지만 일단 한번 해보죠.

어때요, 꽤 괜찮죠? 좋아 보이네요. 케이블 정리까지 완벽해요. 그렇죠? 각 서버당 200GB입니다.

좋아요. 당신들은 누구고, 우리 인퍼 팀에 무슨 짓을 한 거죠? 당신만을 위해 작은 조정을 하나 했습니다.

드라이브를 보세요. 같은 위치에 있잖아요. 아니에요, 맨 위에 있는 게 달라요. 정말 싫어요. 왜 그랬어요?

왜 그런 짓을 하는 거죠? 더 중요한 건 제대로 작동하느냐는 건데. 네, 당연히 되죠. 자, 여기 윈도우 데스크톱이 있습니다. 당연하다니, 무슨 소리죠? 안 되는 부분만 편집해서 잘라내야겠네.

제발, 제이크, 문제가 생겼어요. 맙소사, 오류가 하나 발생했네. 와이파이가 다운됐어요. 드라이브 4개가 작동하지 않아요.

정말로 고장 낸 거예요? 어쨌든 윈도우가 보이죠? 네, 지금 윈도우는 맨 아래 서버인 4번에서 실행되고 있습니다.

네. 당연히 와이파이로 원격 접속하고 있고요. 영상 재생이 약간 끊기네요. DNS 서버나 액티브 디렉터리처럼 일반적으로 이런 환경에서 실행할 워크로드에는 영향을 미치지 않을 겁니다. 드디어 액티브 디렉터리를 하는 건가요?

오늘은 안 하지만, 이제 할 수 있습니다. 하지만 AD 라이브 같은 설정이나 영상 재생에 적합합니다. 맨 위에 있는 1번으로 마이그레이션해 보죠.

프로세스가 조금 더 빠르겠지만, 기본적으로는 메모리, 즉 RAM에 있는 내용을 복사하는 겁니다.

그리고 거의 다 되면 운영 체제를 아주 짧은 시간 동안 일시 중지하고 마지막 아주 작은 부분을 복사하면 끝입니다.

정말 멋지네요. 저장 공간은 이미 거기에 있으니까 정확히 이전과 똑같은 상태인 거죠? 그러니까 실제 다운타임, 즉 경험에 대한 중단으로 보면 17초, 아니, 270밀리초네요.

어, 다른 쪽을 가리키는 줄 알았어요. 아니요, 17초는 전체 과정이에요.

아, 네, 네, 그게 일종의 다운타임이라고 할 수 있겠네요. 아니, 왜냐하면 이걸 가상 데스크톱처럼 사용하는 사람이 있다면 0.25초 정도 깜빡이는 것만 보이고 나머지는 아무것도 변한 게 없을 테니까요.

더 현실적인 데모를 보여주고 싶었어요. 자, 이리 와 봐요.

여기 플렉스 서버가 있고, 비디오가 몇 개 있는데, 이건 1번 서버에 있어요. 좋아요, 이제 비디오를 재생해 볼게요.

플렉스 서버를 다른 장치로 옮길 건데, RAM을 초당 2.5GB로 복사하고 있어요. 그러니까 초당 2.8GB 정도인데, 꽤 빠르네요.

아직 아무것도 안 했는데, 벌써 다 됐고 비디오 재생 중단도 없네요. 다른 많은 애플리케이션과 마찬가지로 비디오 재생은 버퍼를 사용하여 서비스의 작은 중단을 숨기거든요.

이 경우에는 비디오를 작은 덩어리로 조금씩 다운로드하고 있는데, 네, 여기서는 대략 10초 덩어리처럼 보이네요. 이는 146밀리초의 다운타임을 충분히 커버할 수 있죠.

와. LAN 캐시로 스팀 다운로드를 해 보시겠어요? 음, 해야죠. 네, 왜 안 되겠어요? 네, CPU 병목 현상이 확실하네요. 24코어 스레드리퍼의 80~90%를 사용하고 있네요.

하지만 여기서 실수를 조금 했다는 걸 깨달았어요.

보세요, CPU 사용량을 볼 수 있어요. 이 스팀 캐시에 할당한 8개 CPU의 %를 사용하고 있어요. 네트워크 트래픽이 증가하는 것도 볼 수 있네요, 좋아요.

컨테이너로 만들었고 VM이 아니라는 점만 빼면요. 컨테이너는 훌륭하고, 약간 더 가볍고, 성능도 더 좋지만, 메인 시스템의 커널 내에서 실행되거든요.

컨테이너를 종료한 다음 다른 장치에서 재부팅하겠죠. 괜찮다는 뜻이지만, 다운타임 지연이 더 길어질 거예요. 하지만 '저거 작동하는 건가?' 하는 것보다는 훨씬 짧을 거예요.

I Built a PC that CAN’T Fail… and You Can Too!

I Built a PC that CAN’T Fail… and You Can Too!

스크립트