vSAN分享•
vSAN 架构
虚拟化，diskGroup, 对象，组件，raid Tree, witness
• • •
wintess 机制和实 副本和均衡IO 径和cache策
vSAN和ESXi的关系怎样选择虚拟化管 程序的原因:
超过 70% 的 x86 服务 作负载实施 虚拟化1本身可 持应
刚好位于 I/O 径中 可提供底层存储资源的全局视图
它与硬件 关
VM and ESXi
Virtual SAN 已嵌 vSphere 内核CPU 占 少于 10%
于管 需安装和管 单独的虚拟设备 单点故障
提供最短的 I/O 径
与 vSphere 和 VMware 产品体系 缝集成
软件定义的存储针对虚拟机进 优化 聚合 虚拟化管 程序的体系结构 可在任何标准 x86 服务 上运
将 HDD/SSD 池化为共享数据存储 提供企业级的可扩展性和性能 通过按虚拟机设置的存储策 进 管 与 VMware 产品体系深度集成
vSAN物 数据怎么放-DiskGroup
每台主机都包含为 vSAN 分布式数据存储贡献缓存和容量的闪存设备(全闪存配置)或磁盘和闪存设备的组合(混合配置)。每台主机都有一到五个磁盘组。 每个磁盘组都包含一个缓存设备和一到七个容量设备。
VSAN不仅支持分布式存储的在线横向扩展(Scale Out)，也支持纵向扩展(Scale Up) 通过增加主机，提供存储容量的vsanDatastore可以在线扩大，同时整体的性能也线性增长。
ssd endurance classes
ssd performance classes
magnetic disk classes
在全闪存配置中，缓存层中的闪存设备用于缓冲写入内容。不需要读取缓存，因为容量闪存设备的性能已绰绰有余。全闪存 vSAN 配置中通常使用两个等级的闪存设备: 用于缓存层的容量较低、耐久性较高的设备，以及用于容量层的更经济高效、容量较高、耐久性较低的设备。写入在缓存层执行，然后根据需要转储至容量层。这有助于保持性能， 同时延长容量层中耐久性较低的闪存设备的使用寿命。
在混合配置中，一个闪存设备和一个或多个磁盘配置为一个磁盘组。一个磁盘组最多可以有七个提供容量的驱动器。vSphere 主机中使用一个或多个磁盘组，具体取决于主机中包含 的闪存设备和磁盘的数量。闪存设备充当 vSAN 数据存储的读缓存和写缓冲区，而磁盘构成数据存储的容量。vSAN 将使用 70% 的闪存容量作为读缓存，使用 30% 作为写缓存。
vSAN存啥数据-object在vSAN中最典型的存储块设备就是独立的VMDK、虚拟机主页名字空间和虚拟机交换文件。当然，如果虚拟机拍过快照，则还会创建一个
增量盘对象。如果快照包含有虚拟机的内存，这也会被实例化成一个对象。
vSAN 是一种对象数据存储，主要是由对象和容器(文件夹)组成的扁平分层结构。组成虚拟机的项目表示为对象。以下是您在 vSAN 数据存储上可以看到的最常见对象类型:
虚拟机主目录，其中包含虚拟机配置文件和日志，如 VMX 文件
虚拟机交换文件
虚拟磁盘 (VMDK)
增量磁盘(快照)
性能数据库
vSAN 数据存储上还有一些其他常见对象，例如 vSAN 性能服务数据库、内存快照增量以及属于 iSCSI 目标的 VMDK。
vSAN的object怎么切-RAID tree每个对象包含一个或多个组件。组成对象的组件数目主要取决于以下两个因素:对象的大小以及分配给该对象的存储策略。
host3组件为见证组件，由 vSAN 创建，在两台主机之间发生网络分裂时它可以“打破平衡”并实现仲裁。见证对象将安置在第三台主机上。
vSAN的raid tree
组件是对象的RAID树上的叶 ，分布在VSAN集群中的各个主机上。其实，组件是按照两种主要的技术分布的:Striping(条带)， 即RAID 0;和Mirroring(镜像)，即RAID 1。简 之，条带即组件。
vSAN 存储策 有哪些特点
VMware 的 Storage Policy-Based Management (SPBM) 可实现存储服务的精确控制。与其他存储解决方案一样，vSAN 可提供可用性级别、容量消耗和性能条带宽度等服务。 一条存储策略可包含一个或多个用于定义服务级别的规则。
可以使用新的 vSphere Client、旧版(“Flex”)vSphere Web Client 或通过 PowerCLI/API 创建和管理存储策略。策略可以分配给虚拟机和个别对象，如虚拟磁盘。应用需求发生变化时， 可轻松更改或重新分配存储策略。无需停机，也无需在数据存储之间迁移虚拟机，即可执行这些修改。SPBM 允许以虚拟机为单位精确地分配和修改服务级别。
vSAN software components
Local Log Structured Object Management - LSOM
LSOM works at the physical disk level, both 4lash devices and magnetic disks. It handles the physical storage for Virtual SAN components on the local disks and
the read caching and write buffering for the components.
Distributed Object Manager - DOM
DOM is responsible for the creation of virtual machine storage objects from local components across multiple ESXi hosts in the Virtual SAN cluster by implementing distributed RAID. It is also responsible for providing distributed data access paths to these objects. There are 3 roles within DOM; client, owner and component manager.
Client: Provides access to an object. There may be multiple clients per object depending on access mode.
Owner: Coordinates access to the object, including locking and object con5iguration and recon5iguration. There is a single DOM owner per object. All objects changes and writes go through the owner. Typically the client and owner will reside on the same host, but this is not guaranteed and they may reside on different hosts.
Component Manager: Interface for LSOM and the physical disks. A node’s DOM may play any of the three roles for a single object
Cluster Level Object Manager - CLOM
CLOM ensures that an object has a con4iguration that matches its policy, i.e. stripe width or failures to tolerate, to meet the requirements of the virtual machine. Each ESXi host in a Virtual SAN cluster runs an instance of clomd, which is responsible for the policy compliance of the objects. CLOM can be thought of as being responsible for the placement of objects and their components.
CMMDS discovers, establishes and maintains a cluster of networked node members, It manages the inventory of items such as Nodes, Devices, Networks and stores metadata information such as policies, distributed RAID con4iguration, etc.
Reliable Datagram Transport - RDT
RDT, the reliable datagram transport, is the communication mechanism within Virtual SAN. It is uses TCP at the transport layer and it is responsible for creating and destroying TCP connections (sockets) on demand.
witness机制
在RAID1有两个副本的情况下，如果主机之间失联，将无法分辨这到底是主机故障 还是网络分区的情况。因此，需要在配置中引入一个第三方，这就是见证。vSAN中 的一个对象要被认定为可用，必须满足以下两个条件:
1. RAID树必须允许数据访问(RAID-1必须至少有一个完好的副本，RAID-0必须 所有的条带都完好)。对于RAID-5和RAID-6配置来说，RAID-5要求4个组件中必须 有3个可用，而RAID-6则是6个组件中必须有4个可用。
2. 在vSAN的早期版本中，规则是必须有超过50%的组件可用。从vSAN 6.0开始， 引入了和组件相关联的投票(vote) ，规则被更改为投票至少要超过50%。
在前面的例子中，只有当能同时访问到一个副本和一个见证，或者同时访问到两个 副本(无见证)的时候，才能够访问这个对象。这样，在出现网络分区的情况下， 至少有部分群集可以访问这个对象。
witness大小通常为2M左右，里面存放着对象的meta数据，当任意一个节点发生故障时，剩余节点仍然可以继续提供服务。但经常我们会发现创建完vSan后witness数
量不止一个，这就要从witness的组件定义说起，witness按照组件定义可以分为三种:
1.primarywitness，当主机节点数不满足storagepolice时，才会出现该witness。举例说明，当FTT=2时，按照要求此时至少需要5台host，当前环境中的host主机只有4台
这时就会出现primary witness，当环境中满足5台host后，primary witness就会消失。
2.secondary witness，当故障发生后剩余的节点会产生选举，确定出哪一个新的节点承载原有节点上的active对象，但每一个host主机上所承载的对象总数不会相同，
时的选举就处于一种不公平的状态，secondary witness就是为了避免该状态的产生，让每一个host主机上的对象数量相同(只是对象的数量，而不管对象的大小)，
要注意
的是，secondary witness是为了保证
已经承载有对象
3.tiebreaker witness，当进行完上述两步之后，为了保证总对象数量为奇数，此时会添加一个tiebreaker witness
组件的主机之间的组件数一致，不是群集中所有ESXi主机，结合上图得知esxi-01就不会产生witness组件。
需
， 此
vSan6.0中每个对象的最大值为255G，所以在此处会将wmdk强行分割成2个对象，多余的1G被meta数据融合，于是整个raid1中就存在4个对象。此时要求至少需要3个节点，当前环境有4个host主机，所以primary witness就不会出现，而每个host上都只有一个对象，secondary witness也不会 出现，所以此时只会看到1个tiebreaker witness。
vmdk被分割成了3个对象，从raid0上能看出esxi60与esxi80上各有2个对象，esxi50和esxi70上只有 一个对象，所以坐在esxi50和esxi70上各生成一个secondary witness，从而使每个host上的对象数量 一致，然后又因为此时的对象总数是8个，所以还会再生成一个tiebreaker witness对象用于保证总 数为奇数，此时看到的witness总数就为3个。
vSAN怎么提 空间 率
当一个磁盘的可用空间低于 20% 时，vSAN 将自动尝试通过将该磁盘的数据移动 到 vSAN 集群中的其他磁盘来平衡容量利用率。如果存在许多大型组件，则实现磁 盘容量平衡的集群可能更困难。vSAN 6.6 将大型组件拆分为较小组件来实现更好 的平衡，从而提高效率。
提供空间 率的 段:unmap、deduplication and compression
副本如何重新构建和整合
智能判断 判断继续构建全新副本更高效还是更新重新上线的现有副本更高效，选择最高效的方法 副本整合 如果故障域已包含 vSAN 组件副本，并且没有额外容量来放置需要撤出的副本，vSAN 现在能够 将它们整合为单个副本。最小的副本首先移动，这样一来，数据重建量将会减少，并且临时容量使用量也会
减少。
••
副本如何 适应重新同步
vSAN 6.7 中引入了自适应重新同步功能，可确保在 I/O 改变时为虚拟机 I/O 和重新同步 I/O 提供公平份额的资源。
当 I/O 活动超出可持续磁盘组带宽时，自适应重新同步可保证虚拟机 I/O 和重新同步 I/O 的带宽级别。在无争用期间，虚拟机 I/O 或重新同步 I/O 可以使用额外的带宽。如果没有执行重新同步操 作，则虚拟机 I/O 可以使用 100% 的可用磁盘组带宽。在无争用期间，可以保证重新同步 I/O 获得磁盘组可以使用的总带宽的 20%。这样可以进一步优化资源使用。
vSAN怎么探测Degraded Device
A degraded drive is determined by measuring the average latency of the drive and detecting excessive latency for an extended period of time. A degrade drive is one where the average write IO round trip latency for four or more latency intervals distributed randomly within approximately a six hour period exceeds pre- determined latency thresholds for a drive. The magnetic drive (HDD) latency threshold is 500 milli-seconds for write IO. The flash device (SSD) latency threshold for read IO is 50 milliseconds while the IO latency for write IO is 200 milliseconds.
1. Preventative evacuation in progress. A yellow health alert is raised so that administrators know there is an issue. vSAN is proactively compensating for the degraded device by migrating all active components from degraded drive. No administrator action required.
2. Preventative evacuation is incomplete due to lack of resources, i.e., a partial evacuation of active components. A red health alert is raised to signify a more serious issue. An administrator will need to either free up existing resources, e.g., deleting unused VMs, or add resources so that vSAN can complete the evacuation. This scenario might occur when there is relatively little free capacity remaining in the cluster – yet another reason we strongly recommend keeping 25-30% free “slack space” capacity in the cluster.
3. Preventative evacuation is incomplete due to inaccessible objects. The remaining components on the drive belong to inaccessible objects. An administrator should make more resources available in an attempt to make the object accessible. The other option is to remove the drive from the vSAN configuration by choosing “no data migration” when the drive is decommissioned.
4. Evacuation complete. As you can imagine, this is the most desirable state for a drive that is in a degraded condition. All components have been migrated from the drive and all objects are accessible. It is safe to remove the drive from the vSAN configuration and replace it when convenient to do so.
according to https://blogs.vmware.com/virtualblocks/2018/05/25/vsan-degraded-device-handling
IO 流程-写操作
Guest OS issues write operation to virtual disk
Owner clones write operation
In parallel: sends “prepare” operation to H1 (locally) and H2
H1, H2 persist write operation to Flash (log)
H1, H2 Acknowledge prepare operation to owner
Owner waits for ACK from both ‘prepares’ and completes I/O.
Later, the owner commits a batch of writes to hard disk or 4lash used as capacity.
IO 流程-读操作
The Guest OS issues a read request from disk
Owner chooses which mirror copy to read from. The owner of the storage
object will try load balance reads across replicas and may not necessarily read from the
local replica (if one exists). On Virtual SAN, a block of data is always read from same mirror which means that the data block is cached on at most on one 4lash device (SSD); this maximize
effectiveness of Virtual SAN’s caching
At chosen replica (H2): read data from read cache, if it exists.
Otherwise, we incur a read cache miss so we must read from magnetic disk and placed in the read cache
Return data to owner
Owner completes read operation and returns data to VM
cache 策 数据下刷周期: 适应算法，
综合考虑包括rate of incoming I/O, queues, disk utilization,
and optimal batching
把写到同一个磁盘上的数据成批攒够才下刷
当flash还有大量空间的时候不刷 (避免对磁盘同一个地方的反复写)
vSAN写ssd cache的block size是4K， 下刷数据到capacity layer 的block size 1M, 1M 也是容量层的条带大小。
70% read buffer, 30% write cache;
write cache下刷的数据还会在read buffer里保存一会直至不用 (新版本改进)
HDD: 聚合到分散的小写批量写到某个HDD 磁盘 SSD:缓存热点数据
•
•
•
•
•
vsan-troubleshooting-reference-manual.pdf
vsan-671-administration-guide.pdf vmware-virtual-san-6.2-performance-with-online-transaction-processing-workloads.pdf
参考
https://blogs.vmware.com/vsphere/2014/04/vmware-virtual-san-witness-component-deployment-
•
logic.html
• • •
Storage Workload Characterization and Consolidation in Virtualized Environments http://www.mamicode.com/info-detail-1181990.html
https://storagehub.vmware.com/t/vmware-vsan/vmware-vsan-6-7-technical-overview/object-rebuilding- resynchronization-consolidation-1/