我对存储不太熟悉。关于使用SAN用于存储运行物理机器和虚拟机,我有一些问题。
是否可以从附加到物理服务器的SAN存储启动操作系统?如果是这样的话,它是否有不利的一面?假设操作系统有多个驱动器,这个服务器安装了SQL Server,还有其他用于数据、日志和临时数据库的驱动器都来自SAN。如果操作系统是从本地硬盘驱动器启动的,那么它的性能会比SQL数据文件保持在SAN上更好吗?高IOPS?潜伏期?
我正在尝试比较下面的3和量化。
物理机器-本地驱动的引导操作系统和SAN的其他
物理机-启动操作系统和来自SAN的其他驱动器
虚拟机.超V主机本地驱动器上的虚拟磁盘,vSAN上的SQL Data/log/Temp
虚拟机- vSAN中的虚拟磁盘、SQL数据/log/Temp
最后一个会比其他人表现差吗?
谢谢
发布于 2019-08-25 12:36:15
从SAN出发这几天很少见。我经常看到的管理程序是从SD卡启动的。然后,您可以为VM拥有100%的本地存储空间,或者专门为VM使用SAN。如果从SD卡引导是不合适的,也可以只启动PXE-启动虚拟机监控程序。
为了回答你的具体问题:
是否可以从附加到物理服务器的SAN存储启动操作系统?
是的,是这样的。许多数据中心/企业网卡都内置了必要的iSCSI协议来促进这一点。
如果是这样的话,它是否有不利的一面?
是啊,很多。复杂性和脆弱性是最大的。说实话,没有那么多的收获。
假设操作系统有多个驱动器,这个服务器安装了SQL Server,还有其他用于数据、日志和临时数据库的驱动器都来自SAN。如果操作系统是从本地硬盘驱动器启动的,那么它的性能会比SQL数据文件保持在SAN上更好吗?
最好在本地存储中拥有所有数据文件。对于数据库服务器,我认为SAN是一种即将结束的媒介。本地存储现在比SAN存储快得多(即使有40 40Gbps连接)。2019年级硬件上的单个NVMe驱动器可以限制在4GB/秒以下,超过30 30Gbps。在一个驱动器上。花不了那么多钱。在未来,一旦PCI-E4.0开始在下一代服务器上发布,有效地提高了这一潜在的速度。AMD服务器有超过128个PCIe 4.0通道,这给您提供了每个套接字超过250 2Tb/秒(2TB/秒)的潜力。抱歉,但我认为SAN是现代世界的一种死亡媒介。
此外,MSSQL不再需要群集系统的共享存储。使用AlwaysOn高可用性,您可以在没有共享存储的情况下获得高可用的SQL服务器(尽管所有服务器上的存储布局在每个节点上看起来都是相同的)。
最后一个会比其他人表现差吗?
与本地存储相比,它们的性能都很差。然而,我意识到这并不是你真正要问的问题,我只是希望你没有在2019年买到一辆新的SAN,你仍然有机会重新评估。
发布于 2019-08-25 12:34:55
让我们来看看这些;
物理机器-本地驱动的引导操作系统和SAN的其他
现在到处都有这样的系统在运行,特别是像非虚拟化数据库服务器这样的工作方式,如果您需要最低的延迟并获得每一项性能的访问CGI呈现场通常也是这样工作,这是很好和非常有用的。
物理机器- SAN的引导操作系统和其他驱动器
这些年来,我已经做过一两次了,通常它比我想的要“易碎”一些,是的,它可以工作,但比本地磁盘选项需要做更多的工作,而实际上,你所做的只是通过不购买引导对和磁盘控制器在服务器上节省一点额外的费用--我个人认为我在将来不会使用这个。
虚拟机.超V主机本地驱动器上的虚拟磁盘,vSAN上的SQL Data/log/Temp
当然,这很好,有很多VM都是这样运行的--大多数AWS的VM/实例都是这样工作的,它确实很流行。如果您选择的虚拟机管理程序不允许您将VM从一个本地磁盘迁移到另一个本地磁盘和该主机的磁盘,那么有时您可能会忽略虚拟化的一个好处,即从主机迁移所有VM的能力,以便在不影响用户的情况下修复/升级/修补VM。您在这里提到vSAN,您指的是哪个产品,如果您说的是VMware的vSAN产品,那么它会改变事情,因为您可以在本地运行磁盘,防止失败,并且有能力从主机迁移到主机--也许回来是为了澄清这一点?
虚拟机- vSAN中的虚拟磁盘、SQL数据/log/Temp
在公司环境中,这可能是目前最常用和最受信任的方法(尽管随着分布式文件系统(如vSAN )的真正起飞,这种情况可能会发生变化)。
至于最后一个选项的性能,它完全取决于您使用的集中式磁盘阵列/S以及访问它们的通信方法。如果您对缓慢的磁盘阵列使用1 1Gbps以太网,那么它肯定会比使用本地磁盘慢,我喜欢的阵列制造商,加上40 1Gbps的FCoE,比我可以直接连接到服务器栏NVMe驱动器的任何东西都快得多。所以它确实取决于集中式存储是什么。
我希望这对澄清你的选择有所帮助。
发布于 2019-08-25 20:59:07
我不知道这种做法有多罕见,我见过很多,但我想这取决于环境。
我通常看到SAN的Boot是在使用Blade服务器的时候。由于典型的刀片服务器只有两个磁盘槽,所以对于可能需要多兆字节空间的数据库服务器来说,这可能是相当有限的。此外,它是快速和容易更换一个失败的刀片,简单地更换刀片,而不必担心的人这样做,以移动磁盘,而不是让他们在正确的插槽。这仍然需要新刀片中的HBA配置如下所述。
从SAN启动Windows或Linux很简单,您需要与存储管理员一起工作,从HBA为他们提供WWN (通常是两个冗余路径的HBA接口)。一旦存储人员提供了启动LUN,启动服务器并在POST期间输入HBA BIOS。扫描可用的LUN并告诉HBA使用它来引导。确保HBA是启动顺序中的第一个设备,您的Windows安装应该看到它并提供安装到该LUN。最初只配置Boot可能是最简单的,然后在安装OS之后,添加所需的任何额外数据LUN。
https://serverfault.com/questions/980621
复制相似问题