blocks|key|897837|text|这通常是多播图像出现的地方。类似Clonezilla或ghost的东西支持发送数据多播，这将允许您一次将图像推送到所有500个系统，其速度基本上与将图像推到1系统的速度相同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

This is usually where Multicast imaging comes along. 
Something like Clonezilla or ghost supports sending the data multicast which would let you push out the image to all 500 systems at once at basically the same speed as pushing the image out to 1 system.

blocks|key|6144902|text|雪崩安装程序的岩层+linux集群发行版，是基于bittorrent的，并且扩展得很好。它还带您从PXE启动到运行系统。尽管如此，您还是依赖于使用rocks+(基于CentOS)和按岩石方式做事。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|entityMap|0|LINK|mutability|MUTABLE|url|http://www.rocksclusters.org/rocks-doc/papers/two-pager/paper.pdf|1|http://www.rocksclusters.org/wordpress/^0|0|6|0|7|2|1^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@$A|N|B|O|1|P]|$A|Q|B|R|1|S]]|C|$]]]|D|$E|$5|F|G|H|C|$I|J]]|K|$5|F|G|H|C|$I|L]]]]

The <a href="http://www.rocksclusters.org/rocks-doc/papers/two-pager/paper.pdf" rel="nofollow noreferrer">Avalanche installer</a> of the <a href="http://www.rocksclusters.org/wordpress/" rel="nofollow noreferrer">rocks</a> linux cluster distro, is bittorrent based and scales nicely. It also takes you from PXE boot to running system. Although, you're tied to using rocks (CentOS based) and doing things the rocks way.

blocks|key|6145042|text|SystemImager还可以使用位洪流来加快大规模部署.|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|entityMap|0|LINK|mutability|MUTABLE|url|http://wiki.systemimager.org/index.php/Main_Page^0|0|C|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@$A|L|B|M|1|N]]|C|$]]]|D|$E|$5|F|G|H|C|$I|J]]]]

<a href="http://wiki.systemimager.org/index.php/Main_Page" rel="nofollow noreferrer">SystemImager</a> can also use bit-torrent for faster mass deployment.

blocks|key|898053|text|我不会使用多播，因为这会使事情变得更复杂。首先，尽量减少NFS流量，这意味着通过HTTP获得需要安装的包。如果包存储库的web服务器超载，请使用其中的两个，并通过向每个客户端分配不同的服务器来分配负载(例如，ip地址模块2)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|898054|如果有更多的nfsd守护进程成为星体，那么NFS服务器可能会更快。通常，其中只有8个是开始的。|898055|我刚刚使用FAI测量了Debian安装的流量(通过PXE、NFS、HTTP)。当安装4.2GB的软件时，1.3+GB的HTTP+(所有软件包)和100+GB的NFS流量(安装期间的nfsroot+)通过网络发送。这是为一个安装客户端。因此，我想减少NFS流量和分发HTTP流量会有很大帮助。|898056|10+GB的网卡在您的服务器或键合服务器NIC也会有帮助。而且，我认为它不需要同时安装所有的机器，而是在短时间内安装更多。|898057|但是无论如何，首先你必须分析你的瓶颈会是什么。因此，对20台机器进行一些测试。|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|M|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|N|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|O|8|@]|9|@]|A|$]]]|J|$]]

I would not use multicast because this makes things more complicated.
First, try to minimise NFS traffic, that means get the packages you need to install via HTTP. If your web server for the package repository gets overloaded, use two of them and distribute the load by assigning different servers to each client (for example ip address modulo 2).

Your NFS server may be faster if more nfsd daemons will be startet. Often only 8 of them are started.

I just measured the traffic of an Debian installation (via PXE, NFS, HTTP) using FAI. When installing 4.2GB of software, 1.3 GB of HTTP (all the packages) and 100MB NFS traffic (the nfsroot during installation) were send over the network. This was for one install client.
So I guess reducing the NFS traffic and distributing the HTTP traffic will help a lot.

A 10 GB NIC in your server or bonding serveral NIC's would also help.
And, I think it's not need to install all the machine at the same time, but more in a short time frame.

But anyway, first you have to analyse what your bottleneck will be. So make some tests unsig 20 machines for e.g.

blocks|key|6144705|text|关于文件的大规模部署，twitter已经带来了一个基于bittorent的解决方案：谋杀。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|6144706|如果您说的是在您的服务器上安装操作系统，它显然不能使用此解决方案。|entityMap|0|LINK|mutability|MUTABLE|url|https://blog.twitter.com/2010/murder-fast-datacenter-code-deploys-using-bittorrent^0|16|2|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@$A|N|B|O|1|P]]|C|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|C|$]]]|F|$G|$5|H|I|J|C|$K|L]]]]

Concerning the mass deployment of files there is already a solution brought by twitter, based on bittorent: <a href="https://blog.twitter.com/2010/murder-fast-datacenter-code-deploys-using-bittorrent" rel="nofollow noreferrer">Murder</a>. 

If you are talking about installing the OS on your server it obviously won't work with this solution.

blocks|key|6145142|text|我不知道如何使用bittorrent或多播，除非您能够切换到部署映像，而不是执行安装。如果你不是，这里有一个方法来解决这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|6145143|让我们更仔细地考虑瓶颈。CPU不是瓶颈；NFS不需要太多的处理能力。磁盘不是瓶颈；安装RHEL所需的文件不超过几‘s，因此它们应该很容易地安装在NFS服务器的RAM中。网络吞吐量肯定是一个瓶颈；假设一个正在安装的系统平均每秒请求50兆位，那么您至少需要25G的带宽才能满足500个安装。这是很多NIC，或者是一些非常昂贵的。|6145144|这并不意味着你不应该试图通过在合理的范围内向它扔更多的硬件来提高性能。在NFS服务器中获取尽可能多的NIC并将它们连接起来。如果您可以证明时间和成本是合理的，请设置更多NFS服务器。当然，确保您的NFS服务器是调得好。|offset|length|6145145|不管您是否添加了硬件，看看是否通过避免网络拥塞和平衡吞吐量的高峰和低谷来提高性能。要做到这一点，将安装分成几个批次。执行一次安装，并在安装期间绘制吞吐量图。查看该图表，确定您可以同时启动多少次安装，以及何时启动更多批处理的最佳时间。|6145146|例如，假设您可以从NFS服务器(S)传输4Gb/s。您可能会发现，在下载安装程序时，安装程序会在第一分钟复制100+no+/S，然后在安装程序像分区一样工作时不复制数据一分钟，然后在安装程序下载和提取包时，复制50+no/S+3分钟。知道了这一点，您可以计算出您可以启动40个安装，等待一分钟，启动另40个安装，等待5分钟，然后重复该过程。|entityMap|0|LINK|mutability|MUTABLE|url|http://nfs.sourceforge.net/nfs-howto/ar01s05.html^0|0|0|2X|3|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@$F|V|G|W|1|X]]|A|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|Z|8|@]|9|@]|A|$]]]|L|$M|$5|N|O|P|A|$Q|R]]]]

I don't know of a way to use bittorrent or multicast unless you're able to switch to deploying an image rather than performing installations. In case you aren't, here is one way to approach the problem.

Let's think more closely about the bottleneck. CPU isn't the bottleneck; NFS doesn't require much processing power. Disk isn't the bottleneck; the files needed to install RHEL aren't more than a few gigabytes, so they should easily fit in your NFS server's RAM. Network throughput is definitely a bottleneck; assuming one system being installed will request on average 50 megabits a second, you'd need at least 25 gigabits of bandwidth to feed 500 installs. That's a lot of NICs, or a few very expensive ones.

This doesn't mean you shouldn't try to improve performance by throwing more hardware at it, within reason. Get as many NICs as are feasible in the NFS server and bond them. If you can justify the time and cost, set up more NFS servers. Of course, make sure your NFS servers are <a href="http://nfs.sourceforge.net/nfs-howto/ar01s05.html" rel="nofollow noreferrer">well tuned</a>.

Regardless of whether you add hardware, see if you get an increase in performance by avoiding network congestion and balancing the peaks and troughs in throughput. To do this, break the installs into batches. Perform a single install and graph the throughput during the install. Look at that graph and determine how many installs you can start concurrently and when the optimal times to start more batches are.

For example, let's say you can transfer 4Gb/s from the NFS server(s). Maybe you'll find that an install copies 100Mb/s for the first minute while the installer is being downloaded, then it copies no data for one minute while the installer does work like partitioning, then it copies 50Mb/s for three minutes while the installer downloads and extracts packages. Knowing this, you could calculate that you can start 40 installs, wait one minute, start another 40 installs, wait 5 minutes, then repeat the process.

If you are trying to install 500 Linux system through network installation at the same time, the bottleneck would be the NFS/HTTP/FTP or whatever server holds files you need for installation.

IMO, this can only be solved by adding more installation servers and then round-robin them.

Is there any better solution to this problem? Something like "P2P Linux installation"?

UPDATE:
I need to describe my situation more specificly. Currently I'm deploying RHEL using kickstart+NFS. When I try to deploy 500 RHEL concurrently, the NFS server will have a huge traffic and makes every install process slow. Setting up more NFS servers is a solution but I don't think it's a good one.

What's the best practice of mass Linux system deployment?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

如果您同时试图通过网络安装500个Linux系统，那么瓶颈将是NFS/HTTP/FTP或其他服务器保存安装所需的文件。海事组织，这只能通过增加更多的安装服务器，然后循环运行才能解决.这个问题有什么更好的解决办法吗？比如"P2P Linux安装“？更新:我需要更详细地描述我的情况。目前，我正在使用kickstart+NFS部署RHEL。当我尝试同时部署500 RHEL时，NFS服务器将具有巨大的通信

问大规模Linux系统部署的最佳实践是什么？
EN

回答 6

Server Fault用户

Server Fault用户

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问大规模Linux系统部署的最佳实践是什么？EN

回答 6

Server Fault用户

Server Fault用户

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问大规模Linux系统部署的最佳实践是什么？
EN