Unix 服务器分区和文件系统布局

Unix 服务器分区和文件系统布局

互联网上有很多关于 Unix 服务器分区的相互矛盾的信息,所以我需要一些关于如何进行的建议。

到目前为止,在测试环境中的服务器上,我并不真正关心分区,我配置了一个单片机/和一个交换分区。对于我们的生产服务器来说,这种分区方案似乎不是一个好主意。我找到了一个很好的起点这里,但在细节上似乎很模糊。


基本上,我有一台服务器,我将在其上运行基本的 LAMP 堆栈(Apache、PHP 和 MySQL)。它必须处理文件上传(最多 2GB)。该系统有一个 2TB 的 RAID 1 阵列。

我计划设置:

/         100GB 
/var     1000GB (apache files and mysql files will be here), 
/tmp      800GB (handles the php tmp file)
/home      96GB
swap        4GB

这听起来合理吗,还是我把事情复杂化了?

答案1

在布置分区时要记住的一件事是故障模式。通常,这个问题的形式是:“当分区X满了吗?”亲爱的 voretaq7 提出了这个问题,因为满了/会导致许多难以诊断的问题。让我们看一些更具体的情况。

如果存储日志的分区已满,会发生什么情况? 您会丢失审计/报告数据,有时攻击者会利用这些数据来隐藏他们的活动。在某些情况下,如果您的系统无法记录新用户的登录事件,它将不会对其进行身份验证。

当基于 RPM 的系统/var已满时会发生什么? 包管理器将不会安装或更新包,并且根据您的配置,可能会静默失败。

填满分区很容易,尤其是当用户能够写入时。为了好玩,运行此命令并查看您可以多快创建一个相当大的文件:cat /dev/zero > zerofile

它不仅仅是填充分区,当您将位置放在不同的挂载点时,您还可以自定义它们的挂载选项。

/dev/当没有安装时会发生什么noexec 由于/dev通常认为它由操作系统维护,并且仅包含设备,因此它经常(有时仍然)用于隐藏恶意程序。关闭它noexec允许您启动存储在那里的二进制文件。

出于所有这些原因,以及更多原因,许多强化指南将讨论分区作为要执行的第一步之一。事实上,如果你正在构建一台新服务器,如何对磁盘进行分区几乎就是第一的你的事情决定,而且往往是最难在之后改变的。有一个群体叫做互联网安全中心提供大量易于阅读的配置指南。您很可能可以找到适合您特定配置的指南操作系统看看他们可能会说什么具体内容。

如果我们看一下 RedHat Enterprise Linux 6,推荐的分区方案如下:

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

所有这些更改背后的原则是防止它们相互影响和/或限制可以在特定分区上执行的操作。以 的选项为例/tmp。这意味着不能在那里创建任何设备节点,不能从那里执行任何程序,也不能对任何东西设置 set-uid 位。就其本质而言,/tmp几乎总是全世界可写的,并且通常是一种仅存在于内存中的特殊文件系统。这意味着攻击者可以将其用作放置和执行恶意代码的简单登台点,然后崩溃(或简单地重新启动)系统将清除所有证据。由于 的功能/tmp不需要任何这些功能,我们可以轻松禁用这些功能并防止这种情况发生。

日志存储位置,/var/log并被/var/log/audit分割出来以帮助缓冲资源耗尽。此外,当日志存储开始填满时,auditd 可以执行一些特殊操作(通常在安全性更高的环境中)。通过将其放在其分区上,这种资源检测性能会更好。

更详细地说,并引用mount(8),这正是上面使用的选项:

禁止执行不允许在已挂载的文件系统上直接执行任何二进制文件。(直到最近,仍然可以使用 /lib/ld*.so /mnt/binary 之类的命令来运行二进制文件。此技巧自 Linux 2.4.25 / 2.6.0 起失效。)

节点 不要解释文件系统上的字符或块特殊设备。

诺苏伊德不允许 set-user-identifier 或 set-group-identifier 位生效。(这看似安全,但实际上如果你安装了 suidperl(1) 则相当不安全。)

从安全角度来看,这些都是非常好的选项,因为它们允许您对文件系统本身进行保护。在高度安全的环境中,您甚至可以将选项添加noexec/home。这将使标准用户更难编写用于处理数据的 shell 脚本(例如分析日志文件),但它也会阻止他们执行提升权限的二进制文件。

另外,请记住,root 用户的默认主目录是/root。这意味着它将位于/文件系统中,不是/home

具体分配给每个分区的大小可能因系统工作负载而异。我管理的典型服务器很少需要人员交互,因此分区/home根本不需要很大。这同样适用于它,/var因为它往往存储经常创建和删除的临时数据。但是,Web 服务器通常将/var/www其用作游乐场,这意味着要么也需要将其放在单独的分区上,要么/var/需要将其做大。

过去我曾建议将以下内容作为基准。

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

这些需要根据系统的用途和环境的运行方式进行审查和调整。我还建议使用 LVM,不要分配整个磁盘。如果需要,这将允许您轻松扩展或添加分区。

答案2

忽略底层 RAID 阵列(有关 RAID 阵列级别以及何时使用它们的更多详细信息,请参阅此问题),让我们集中讨论一下你提出的核心问题:
“我应该如何布局我的 Unix 服务器的文件系统?”


一个巨大的分区有什么问题/

正如您在问题中提到的,许多 Linux 发行版(尤其是像 Ubuntu 这样的“桌面”发行版)使用非常简单的文件系统布局:/[swap]

该方案的优点是简单—— 这对于 DOS/Windows 用户来说非常棒,他们习惯于在家用电脑上使用“硬盘”作为一个巨大的整体容器(C:\),将东西转储到其中,而且您不必担心文件系统空间不足 —— 只需确保保持在磁盘容量以下,一切(至少在理论上)就没问题了。

不过,单文件系统方案有几个缺点 - 最常提到的缺点是,当根文件系统填满时(以至于拒绝启动),Unix 系统往往会做出非常糟糕的反应,并且如果所有东西都在写入/(根文件系统),一个任性的程序或用户可能会破坏整个系统。
如果系统崩溃并随后出现文件系统损坏,单个大型文件系统也很容易完全丢失。

上述问题加上强烈的组织意识就是为什么 Unix 服务器通常具有多个文件系统。


如何分解 Unix 文件系统?

所以希望您相信拥有多个文件系统是有意义的。现在的问题是如何将系统划分为逻辑块,以及如何决定每个块获得多少空间?
答案是,您知道并了解您的操作系统将把什么放在哪里。这种理解的起点是hier手册页。大多数 Unix 系统都带有 (man hier来自 Linux 系统, 和man hier来自 BSD 系统),再加上你对代码的本地了解正在安装将要执行的操作将指导您创建合理的分区布局。

我将在这里描述一个通用的分区方案,但该方案应始终进行修改以满足您的特定需求。

通用的 Unix 分区方案

/
    The "root partition", /, does not usually need to be very large.
    It holds the basic items needed to boot the system, mount other filesystems
    and get you to a running, usable, multi-user environment.  It's also what
    is available to you when you bring up the system in single-user ("recovery")
    mode.  
    The contents of / should not change or grow substantially over time.

    NOTE: Anything that doesn't go on one of the other partitions described
          below will wind up taking space on the root partition (/).

/var
    The /var filesystem holds variable data -- log files, email, and on some
    systems databases (like MySQL or Postgres) store their data files here.  
    `/var` should be "Big Enough" to hold all the data you intend to cram into
    it.  I generally advise 10GB for systems that won't have a database or email
    server (just logs).  If you are building a database or mail server you
    should obviously make `/var` larger, or carve out separate filesystems for
    the database/mail data.

/usr
    The /usr filesystem holds "userland" programs, data, manual pages, etc.
    This is where things like the Firefox browser binary live.  On systems that
    will have a lot of large user applications this filesystem may be very large
    (100GB or more), and on stripped-down servers it may be relatively small.  
    A good rule of thumb is that the /usr filesystem should be twice as large
    as you need it to be in order to fit your initial installation of programs.

/home
    The /home filesystem holds user home directories, and on desktop systems is
    the largest and most prone to filling up.  When you download files from the
    internet, create spreadsheets, store a music library, etc. that data is
    stored in your home directory, and it adds up fast.
    It's important to allow enough room under /home for the "accumulated junk"
    you will gather over time, even on servers -- ad-hoc tarball backups, 
    package files you copied over to install, and the like.

特殊文件系统

/tmp and /var/tmp
    The temporary scratch space (/tmp) is "special" -- on most Unix systems
    the contents of /tmp are cleared on reboot, and on many modern systems
    /tmp is a special "tmpfs" (RAM) filesystem for better performance.
    /var/tmp is usually "persistent temporary files" (like vi recovery
    files), and is not cleared on reboot
    The same general rule applies as for all other filesystems: Make sure
    your temporary scratch filesystems are big enough to hold the stuff you
    want to put in them.

[swap]
    Swap Space is used by the kernel when you are running low on RAM --
    The old general rule of thumb was to have at least twice as much swap
    as you did RAM, however on modern systems it's usually sufficient to
    have "enough" swap -- 2GB is a practical lower limit, and an amount
    between half the installed RAM and the total installed RAM is usually
    adequate.
    On modern systems with relatively huge RAM pools (12G and up) it is
    probably not practical to use the system if it's swapping heavily
    enough to warrant the old "Twice the installed RAM" rule.

答案3

像那样划分文件系统的做法源自没有软件 RAID 的时代,那时磁盘驱动器很小,所以您必须使用多个磁盘驱动器,因此,唯一的方法是拆分文件系统并将不同的目录放在不同的驱动器上。这样做的另一个历史原因是,您可以轻松地卸载分区并dump进行备份,而使用 root 则无法做到这一点。如今,此工具已基本失宠,现在可以在 LVM 快照甚至 root 上使用。

几乎没有理由再这样做了。剩下的唯一理由就是,例如,如果你想防止/tmp填满整个磁盘。

如今,这个原因已基本不重要,因为为用户提供一般 shell 访问权限的做法已经过时了,如今的服务器运行着专用服务,例如 Web 或邮件服务器。由于没有随机用户能够运行任意命令,因此您通常不必担心他们会试图填满您的文件系统(即使您这样做了,您也有磁盘配额来阻止这种情况)。

至于使用哪种 raid 级别,您需要记住 raid 的主要目的不是保护数据(这就是备份的目的),而是维持正常运行时间。如果您使用/tmpraid0,那么如果其中一个磁盘发生故障,您的服务器仍会停机,您必须去修复它。您可能还想使用 raid10 而不是 raid1,这样您也可以获得更好的性能。

不拆分文件系统的一个非常好的理由是,如果分配错误,尽管其他地方有足够的可用空间,但文件系统的一部分仍然可能已满。除非您使用 LVM 并留下一些未分配的空间,否则纠正这个问题可能很困难。

答案4

根据您的架构 - 您可能不想实际使用 /tmp,因为它在每次重新启动后都会被清除。如果您的网站最终处理上传,则将其更改为其他位置(通过 php.ini)可能是一个好主意;您可以在其中将其设置为任何挂载点。

正如之前所建议的,强烈建议使用 LVM 并根据需要增加。

我还强烈建议为 MySQL 数据设置一个专用分区(您仍然可以将其安装在 /var/lib/mysql 下)。

相关内容