在一个大的分区上安装Linux真的有多糟糕?

我们将在新服务器上运行CentOS 7。 在服务器内部的raid6中有6个300GB的驱动器。 (存储主要是以40TB RAID盒子的forms存在)。如果格式化为单个卷,则内部容量约为1.3TB。 我们的系统pipe理员认为在一个大的1.3TB分区上安装操作系统是一个非常糟糕的主意。

我是一名生物学家。 我们不断安装新的软件来运行和testing,其中大部分都在/ usr / local。 然而,因为我们有大约12位非计算机精明的生物学家使用这个系统,所以我们也在/ home里收集了很多的东西。 我们的最后一台服务器有一个200GB的分区,在2.5年之后它已经满了90%。 我不希望这种情况再次发生,但我也不想违背专家的意见!

我们如何才能最好地使用1.3TB可用来确保空间是可用的时间和地点,而不是造成系统pipe理员的维修噩梦?

    分区的主要(历史)原因是:

    • 将操作系统从用户和应用程序数据中分离出来 。 在RHEL 7发布之前,没有受支持的升级path,而主要的版本升级需要重新安装,然后在单独的分区(或LVM卷)上具有/home和其他(应用程序)数据,这样可以轻松地保留用户数据和应用程序数据并擦除操作系统分区。

    • 用户无法正确login,并且在完全用完磁盘空间时,系统开始以有趣的方式失败。 使用多个分区可以为操作系统分配硬盘保留磁盘空间,并将其与用户和/或特定应用程序允许写入的区域分开(例如/home /tmp/ /var/tmp/ /var/spool/ /oradata/等), 减轻行为不当的用户和/或应用程序的操作风险

    • 配额。 磁盘配额允许pipe理员防止个人用户使用所有可用空间,中断对系统的所有其他用户的服务。 单个磁盘配额是按文件系统分配的,因此单个分区和单个文件系统仅意味着1个磁盘配额。 多个(LVM)分区意味着多个文件系统,允许更细化的配额pipe理。 根据您的使用情况,您可能需要例如允许每个用户在其主目录中放置10 GB,在外部存储arrays上的/ data目录中放置2 TB,并设置一个大的共享临时区域,任何人都可以将数据集转储到主目录并且政策变得“充满”的地方,但是当这种情况发生的时候,什么也没有发生。

    • 提供专用的IOpath 。 你可能有一个固态硬盘和旋转磁盘的组合,并会很好地解决它们的不同。 在通用服务器中不是一个问题,而是在数据库设置中很常见的一个问题,就是为了不同的目的也分配特定的主轴(磁盘)来防止IO争用,例如事务日志中的单独磁盘,实际数据库数据的单独磁盘以及单独的磁盘临时空间。 。

    • 启动您可能需要单独的/boot分区。 历史上,为了解决超过1024个柱面限制引导的BIOS问题,现在更多的时候需要支持encryption卷,支持某些RAID控制器,不支持从SAN启动的HBA,或者不能立即由安装程序支持的文件系统等。

    • 调整您可能需要不同的调整选项,甚至完全不同的文件系统。

    如果你使用硬分区,你或多或less必须在安装时正确安装,然后单个大分区并不是最差的,但是它确实带有上面的一些限制。

    通常情况下,我build议将主卷分区为单个大型Linux LVM物理卷 ,然后创build适合您当前需求的逻辑卷和剩余的磁盘空间, 直到需要时为止

    您可以根据需要扩展这些卷及其文件系统(这是在实时系统上可以完成的简单操作),也可以创build其他文件系统。

    缩小的LVM卷是微不足道的,但通常会缩小其上的文件系统不被支持 ,应该可以避免。

    使用多个分区的概念是,在错误的地方使用完整的分区不会导致整个系统意外工作。

    考虑一下机器上的一个进程,填满一个日志文件相当快,直到没有可用的空间。 例如,在单分区机器上,可以防止系统向/ tmp写入新数据。 如果有另一个进程要写入/ tmp,它可能会退出并出现错误,导致意外的行为。

    如果对用户或进程正常写入的地方(/ home,/ var,/ tmp)使用不同的分区,则可以避免这种情况。

    我会build议你检查你的旧服务器哪些文件夹往往变大。 你可以在命令行上用

     du -h -d 1 / 2> /dev/null 

    你会看到大部分数据在哪里积累,并适当地devise你的下一个系统。 “-d 1”将输出限制为只有一个级别的文件夹深度,使其更具可读性。

    有一个单独的大分区的主要问题是填充文件系统是可能的,不可能再login。

    因此,用户root拥有/home之外的home文件夹( /root )。 如果文件系统在某些情况下被填满,即使root无法login,也无法修复系统。

    这就是为什么您通常为/var/tmp/home创build单独的挂载点,以便能够至less以root用户身份login,以便在其中一个其他分区被填满时修复系统。

    恕我直言,有一个分区作为/是相当合理的。

    但是你可以使用lvm(逻辑卷pipe理器)。 使用所有磁盘作为lvm组,但为/,/ home,/ usr创build小逻辑磁盘,无论您的系统pipe理员喜欢什么。 然后进行一些监视,你知道,当你的系统开始充满,并展开你需要的磁盘。 lvresize和resize2fs是在线工具,您可以在不重新启动服务器的情况下进行扩展。 但是,你不能减less磁盘,所以你需要开始合理的小,增加你所需要的。

    Linux的大单分区设置问题很less,但有很大的回报。

    更改分区布局有点困难和危险,如果没有很长的停机时间,你往往无法做到这一点。

    它的唯一好处是你有一些保护磁盘的问题。 但是你会经常发现这些问题。 想象一下,如果你的一个分区已经满了, 你不能使用其他分区上的空间,即使它们几乎是空的

    一些专业的系统pipe理员对此有不同的看法。 他们说,拥有多个分区可以使你的系统更加可靠,而且在分区之前你必须知道你的分区有多大。 在我看来,这不能说是系统的灵活性的一个可怕的缺点,他们的真正动机是他们只是喜欢玩分区地图

    有一个名为lvm的简单系统,它可以实现对“分区”(以其术语,卷)进行即时移动/resize。 但是,在一个单一的本地部门服务器,恕我直言,这通常是不需要的。

    分区有两个主要原因:

    1. 保持静态数据远离非静态数据
    2. 使公开的数据远离私人数据

    第一个原因是最明显的 – 你需要隔离那些没有文件的区域,而你特别想保护/避免无法启动的系统。 例如,/ var目录通常是存储日志文件的地方(var代表“variables”),这就是为什么/ var倾向于安装在从/分开的分区上。

    上面的第二个原因没有被引用(我上次在15年前的Veritas Volume Manager课程中听说过),而且这真的只与许多人login和执行工作的系统有关。

    有效的分区是有一些艺术的,这也许就是为什么有些系统pipe理员把它做得太远了(IMO)。 你不仅需要知道里面的文件系统,而且还必须知道预期的用途。 我个人认为这是一个相当老式的方法,与当今服务器的使用方式越来越不相关。

    作为一名软件开发人员,我尤其厌倦了Ops部门构build的虚拟机部署虚拟分区scheme,严重限制/ tmp,/ home,/ var和/的大小,而不pipe可用的总磁盘空间如何,不要像/ usr或/ opt这样明显的select。 这些机器通常会把你所要求的磁盘空间中的所有东西都放到“/ stuff”卷中,这样你不可避免地会把所有的东西都安装到一个文件中,但这并不是一种安慰。 最终的结果是,我们经常花更多的时间来洗牌文件,并发送警告电子邮件,而不是做任何真正的工作。

    有一个单独的分区没有任何固有的“坏”。 在任何系统上,你都应该主动监视你的磁盘使用情况,并采用明智的内务pipe理策略(例如日志轮换,主目录配额),所以唯一真正的问题是:你想要关心多less个单独的文件系统?

    因此,我会说: 除非您对您的特定用例有效地划分系统的能力充满信心,否则不要进行分区

    恕我直言,这完全取决于你。 首先考虑一些事情,尽pipe完全是相对的。

    • 这个系统会经常pipe理吗?
    • 这个系统会被一个或多个用户使用吗?
    • 这个系统是作为桌面还是服务器,还是两者兼而有之?

    由于可以考虑(几乎)任何目录的安装点,所以还应该考虑包含有所增长的数据以及包含不断增长的数据的内容。

    您会惊讶于Linux系统(有点增长的数据)需要运行多less,以及数据增长需要多less(通常是/ var / opt / home / srv)

    这也取决于你如何定义这个系统的使用,它概述了分区需求。 包括LVM的使用。

    一个典型的桌面系统将需要大约20GB的软件安装负载,所有其余的分配给一个专用的/家会做的很好。 LVM会在系统上造成较小的开销,在这种情况下并不是那么有好处。 虽然意见可能不同。

    在服务器上,安装的软件不太可能像桌面系统一样dynamic。 具有典型文件系统组件的实际挂载点比如:/ tmp / var / usr / home / opt / srv也更为明智。build议不要使用LVM。

    这为您的系统提供了很好的模块性,同时也可以做一些愚蠢的事情,例如将分区克隆到虚拟机中。 或者使用dd创build块级备份。

    基于一些经验,这里有一些笔记。 另外考虑让多个安装点允许更好的控制,将一个快速或慢速的磁盘设备分配给一个安装点可以造成一个不同的世界,并且可以明显提高成本效率。

    Mounpoint /

    • 1GB(如果对/ var / usr / opt / home / tmp使用单独的挂载点)
    • +10或甚至+ 20 GB,如果作为一个单独的/家庭的桌面系统使用

    如果使用mountpoint / home

    • 分配所有可用空间(如果使用的话)/ home ne

    如果使用mountpoint / opt

    如果使用mountpoint / usr

    • 这是一个棘手的问题,并且非常依赖于已安装的软件基础

    如果使用mountpoint / var

    • 这是一个棘手的问题,并且非常依赖于已安装的软件基础
    • 例如,数据库将数据写在基于Debian的系统上,如果不是全部的话
    • 有一个单独的/ var / tmp不是不合理的

    如果使用mountpoint / tmp

    • 考虑tmpfs的存在和分配/ tmp到RAM
    • 考虑一些应用程序可能会在这里写很多数据

    这允许独立于用户数据来备份,恢复或重新安装操作系统。 这给你自由,独立和安全。

    1. 迁移到另一个仍然保留绝大多数用户数据的Linux发行版会更容易。

    2. 通过应用操作系统分区的备份(需要双启动),很容易恢复有问题的更新。 这个备份甚至可能会比较老 – 你可以应用它,稍后更新到知名的稳定版本。

    3. 如果您不喜欢最近应用的“主要升级”(需要双启动),则很容易恢复到以前版本的操作系统。

    对于这种方法的最大潜力,还应该configuration双引导(也可以是CentOS / CentOS),以便在从另一个操作系统运行操作系统时覆盖一个操作系统分区。 而且,当然,您必须至less在几个月后备份系统分区。

    我的简短回答是,即使桌面也不应该使用“一个大分区”。 我最近试图对付我更好的判断,因为它只是一台笔记本电脑,自动安装程序使用了一个分区,我只是点击button。

    当我去安装不同的发行版时,我不得不重新分区我的驱动器,因为安装程序不会安装在现有的发行版上。 它可以和将保持你的/家庭完好如果它在自己的分区。 所以,我最终启动了一个gparted live-cd并缩小了分区,为/ home和其他分区创build了新的分区,将数据移动到新的分区,然后引导到新操作系统的安装程序中。

    理想情况下,放置在SSD上,/ home放在硬盘上,/ var放在硬盘上,/ usr放在SSD或HDD上,具体取决于您计划升级的频率。 / tmp到硬盘。 我通常为共享媒体文件(如mp3和电影)提供另一个分区,从我的/ home使用符号链接。 请注意,/ sbin是根的一部分,是/ bin和/ root。 这就是/ bin和/ usr / bin之间的区别是/ usr是在所有驱动器挂载之前可能无法使用的东西,所以挂载命令不能在/ usr中! 我通常为其他Linux发行版保留一些额外的分区,就像我的硬盘驱动器上有一个分区,以防万一我搞砸了一些非常糟糕的事情,我有另一个现场系统准备好恢复工作。

    对于你可能需要移动东西的服务器,dynamic添加存储,并且需要一直保持,一定要使用LVM!

    首先,我不得不质疑,为什么你在这里发布这个问题,作为一个生物学家,他正与一个显然能胜任的系统pipe理员争论硬盘分区的细节问题! (没有冒犯,只是真的想知道为什么你不相信你的系统pipe理员)。

    所以,有几点意见:

    • 1.3 TB不再是一个大的驱动器。 现在,2TB在桌面环境中是一个或多或less的标准SATA驱动器。

    • 任何Linux发行版的安装都不会超过100GB。 当然,/(根)和(交换)的大小应该很容易通过慷慨地估计它们(对于根)或者通过系统configuration准则(交换)来确定为上限数字。

    • / home的挂载点应该指向你的40TB RAID服务器上的东西。 用户的主目录不需要该数据在该根设备上的任何地方。 把它们放在RAID服务器上可能会给你更好的保护。 而且,它很可能是一个容易扩展的NAS设备,而内置于服务器盒中的小型RAID却不是。

    • 你应该把你的特殊软件放入一个单独的分区(/ usr / local / bin的挂载点),这样你就可以在操作系统更新和根分区擦除时保留这个软件。 否则,你面临的可能性,你将不得不重新安装你的“特殊”的软件应用程序在操作系统升级/修复/任何。

    • 如果你想担心你的系统pipe理,我会问一个不同的问题:在build筑物着火之后,服务器和RAID盒被破坏后的灾难恢复过程是什么? 除非您关心的数据完全处于您的头脑中,否则每个用户都应该询问他们的IT /系统pipe理员。 这个策略应该包括诸如“我们如何复制我们需要的硬件”和“需要多长时间才能备份和运行”等问题。 关于虚拟化服务器的一些讨论可能有助于解决硬件依赖关系的问题,并且无需重新configuration操作系统即可恢复运行(因为可以将其configuration为在“软”设备环境中运行,即使在底层的硬件是完全不同的)

    • 同样,您可能想要问什么策略是保护用户数据免受程序和用户错误数据丢失。 将一个空文件保存在您的研究论文的非常棒的草稿上,或者让用户input错误的命令(例如rm -rf *)将导致数据丢失,就像地震,火灾或其他物理损坏一样。 个别文件恢复的解决scheme与批量灾难恢复最有用的解决scheme有些不同(或可能!)。

    您不必将软件安装到/ usr / local,您可以将所有软件安装在可能位于/ home的不同前缀中。 大多数软件在从源代码编译时都可以这样做,例如运行./configure --prefix=/home/bin

    既然你是一名生物学家,你可能会对很多软件感兴趣,而这些软件没有正确的打包成rpm或者deb,你将不得不从源代码编译它。

    我是一个HPC系统的系统pipe理员,在我们的用户中有很多生物学家,我们在/ apps /文件系统下安装了他们所要求的所有软件,所以我知道大多数软件都可以这样做,非常辛苦 为了解决这个问题,我的同事和我一直在写一个名为EasyBuild (自由和开源)的工具。它可以从源代码编译和安装软件,并将其安装在不同的文件夹中,并为您自动创build一个环境模块文件。实际上可以安装2个不同版本的相同软件,并且没有冲突。

    看看我们可以用一个命令安装的软件包列表 ,作为一个生物学家,你可能会认识到他们中的很多人;-)

    免责声明:我是EasyBuild的开发者