Half Coffee Blog!
我热爱的一切东西~-
一篇vSAN入门
一直想抽空写写 vSAN 这个产品，在 15 年的时候笔者第一次听说 vSAN 这个产品，当时 VMware 还以 VDI 最佳拍档的方式去推广 vSAN，短短两年的时间， vSAN 经过多个版本的更新迭代，无论从功能还是稳定性上均有很大提升，最广泛的应用也由 VDI 变为了承载核心业务。
这篇文章总结一下笔者对 vSAN 的一些学习和使用经验，简单介绍下 vSAN，希望可以用最少的文字介绍清楚 vSAN 的架构、优势以及需要注意的地方。
以下内容仅代表个人观点，如果错误欢迎指正。
01
—
虚拟化的存储
在 NSX 系列文章 NSX从入门到精通(2)：NSX介绍-网络工程师篇 中，简单介绍了虚拟化及 vSphere，本文以这个背景开始介绍存储。
对于企业来说重要的是数据，而承载数据的设备就是存储设备（Storage）。
与个人电脑类似，企业级存储设备一般由多块硬盘与RAID卡组成。通过 RAID 卡可以将多个磁盘组成逻辑的阵列，使得数据分散保存在多个磁盘中，实现高效的读写，实现冗余，避免单个磁盘故障引起的数据丢失。
通常会使用 RAID 1 和 RAID 5 两种配置模式，两种模式使用的算法不一样，最终读写效率、资源利用率也不同，但最终目标都是一致的：可以避免一块磁盘的故障。
RAID 卡及磁盘组成的阵列是纯硬件层面的，对于操作系统来说，最终的使用方式是将其格式化为 XX 文件系统去使用，拿 Windows 系统来说，会格式化成 NTFS 去使用。
在虚拟化出现之后，这样的硬件架构依然可以被使用。
vSphere 有个很重要的功能是进行了虚拟机的封装，一个虚拟机以文件的形式存在，可以任意拷贝到其他其他。为了更精确定义这一个虚拟机需要的资源，会有很多个文件来表示这个虚拟机，例如 .vmx 后缀的虚拟机配置文件、.vmdk 后缀的数据文件等等。
单台服务器做了虚拟化，跑很多的业务，这样没什么问题，但在企业环境下，还必须考虑服务器硬件的故障。因此，vSphere 下有了集群的概念，一个集群视为一个资源池，搭配很多 vSphere 的高级特性后，业务可以运行在集群中任意主机上，不必担心单一主机故障。
下图演示的就是单台服务器故障后 vSphere 的故障恢复机制 HA，可以将故障主机上的虚拟机“迁移”到其他主机运行。
而在这个功能的背后，有一个前提，便是共享式集中存储。这里面的关键词是共享，一个存储可以被多个服务器同时连接，同时读取数据，任意一台服务器故障后，数据不受影响，进而其他服务器可以使用这些数据快速恢复业务。
一般存储会有两个机头（相当于存储的大脑）保证冗余，每个机头会有多个接口保证接口冗余，每个接口都可以对外提供数据访问服务，但这个数量是固定的，在服务器很多的情况下，需要存储交换机的介入，为保证冗余，需要至少两台。
02
—
大数据的到来
章节 1 的架构一直很稳定，直到各种新概念的出现。
几年前和现在比，对个人而言最大的变化是“人手一机”，对于企业最大的变化是“数据剧增”。
短短几年内，用户产生的数据在剧增，对数据的存储、分析等需求也在剧增。
再回到章节 1 看看传统的集中式存储，一下子暴露出很多缺陷：
- 容量有上限
- 所有配件均为专用硬件，一旦设备停产，无法进行硬件升级
- 不能平滑地按照业务需求升级容量和性能
- 严重依赖于存储厂商提供服务
- 上线周期长
- 配置较为复杂，与业务无强关联性，容易出现误操作
- 无法针对业务提供区分式服务
为了解决以上问题，需要做到三件事：即抛弃单点的设计，避免单点性能瓶颈(无集中式主控)；抛弃专有硬件，使用标准硬件搭建存储系统；使用一种灵活的存储管理程序提供存储服务。
而实现的最终效果，便是软件定义的基于服务器集群搭建的分布式存储。
虽然上面的话比较绕口，但我觉得一句话可以完整表达出它的三个特点：
-
软件定义：存储的管理程序必须是基于软件实现的，唯有软件才能做到开放、灵活、快速，适应企业对于存储的种种需求。
-
基于集群：集群代表搭建这样的存储系统，必须有多台服务器的参与，这些服务器需要有相似的配置，提供统一和标准的功能；
-
分布式：分布式可以将数据、IO访问分散到多个节点，让整个存储系统随着节点的增多容量和性能线性增加。
基于上面的概念图，再来看看具体如何去实现。
1、谁提供容量？
如图所示，每台服务器都需要本地安装硬盘来贡献一部分容量。为了让存储性能更佳，需要配置 SSD 硬盘来做读写缓存，HDD 用来提供大容量的存储。
2、如何将每台服务器的提供的硬盘连接起来？
通过网络，为了保证性能，一般需要使用专用的万兆以太网。为了保证网络冗余，也需要两台交换机，双线连接。
这里有个重点是，万兆交换机之间必须互联！
3、向谁提供服务？
如果在虚拟化环境中，则最终使用存储的是虚拟机，前面提到虚拟机以文件的形式保存，所以只需要让虚拟化层可以把文件保存在上面即可。
4、如何提供存储？
传统存储架构下，所有的服务都是要通过存储的大脑–机头来实现。
如果改成了分布式，每个节点都需要提供存储资源，也需要访问存储，因此每个节点都会有相关的组件存在。
03
—
VMware vSAN
VMware 于 2013 年正式推出 vSAN，全名 VMware Virtual SAN，其架构很类似于章节 2 提到的分布式存储架构，在某些设计上更加“完美”，也做到了企业级的安全+消费级的简单。
下面就三个关键词讲解 vSAN ：
池化：
vSAN 做的第一步，是将集群内多个服务器上的多个磁盘进行池化。
1、服务器内部的连接
X86 服务器的架构决定了每个服务器必须有 RAID 卡才能使用硬盘，多块硬盘使用 RAID 卡汇聚到一起再和主板连接。
在每个 vSAN 服务器内，至少需要配置一块 SSD + 一块 HDD，HDD 用于存储容量，SSD 只用于读写缓存。
在 RAID 卡选择上，建议使用支持直通模式（Pass Through）的 RAID 卡。在这种模式下更换硬盘、新增硬盘会非常方便（而如果配置 RAID 来供 vSAN 使用，则很多时候需要重启主机进入 BIOS 来配置）。
可能有人会问不配置 RAID，硬盘坏了数据丢失怎么办？不用担心，vSAN 有自己的冗余机制，下面会讲到。
SSD 70%的容量用于读缓存，30%的容量用于写缓存。默认所有写的数据会被先行放在 SSD 中以减少写延迟，通过一些机制将这些数据逐渐写入到 HDD 中（这个过程叫 Destage）。在从 vSAN 读数据的时候，vSAN 有一套算法来决定哪些数据为热点数据，然后预先缓存到 SSD 加快读取速度。
所以，通常也不建议使用 RAID 卡自带的读写缓存，因为 vSAN 已经有很优化的读写缓存加速了。
在这里需要格外注意的是 vSAN 要求 SSD、HDD、IO Controller 必须在 vSAN 兼容列表内，否则会出现不稳定等情况。
2、服务器之间的连接
一个服务器内部，通过 RAID 卡将硬盘汇聚在了一起，服务器之间，则需要网络保证数据能够互通。
当然，仅依靠以太网，是不能将多个硬盘连接起来，需要有个中介，这个中介就是嵌在 vSphere 中的 vSAN 进程。两个网络节点之间通信，双方必须有 IP 地址才可以，于是有了** vSAN VMkernel**，每台主机都需要一个 vSAN VMkernel 和独立的网络，保证节点之间数据高速、稳定的传输。
有了以上元素，只需在 vSphere 集群中开启 vSAN 功能，所有主机的磁盘会组成一个逻辑的存储池。
故障域：
1、
前面提到了传统存储使用 RAID1 或者 RAID5 来防止单硬盘故障，在分布式存储中，也需要避免单点故障。
vSphere 提供了 HA 功能，保证单台主机故障后业务可以在其他主机上运行，这里故障的单位是“主机”，vSAN 也继承了这一设定（也很合理，因为主机也需要硬件维护，在维护的时候，一台主机能提供的所有存储资源都会下线）。
在这样的设定下，为了保证数据不丢失，数据的存放位置就有讲究了。
同一个虚拟机的同一份数据，必须保存在不同主机上。
结合上面的架构和 vSAN 的网络架构，假如一台主机网络有问题怎么办？（此时主机并不能确定是自己的网络中断还是其他主机中断，只知道无法和其他节点通信。）
这时候需要有个仲裁机制保证同时只有一份数据是活动且是最新的，否则会造成冲突。
于是在上图的架构中，为每份数据再创建一个仲裁文件，保存在第三台主机中。
这便是 vSAN 最简单的架构，此架构允许一台主机故障，当然一台主机上的任意硬件坏掉也是允许的，只要故障发生在一台主机内。
下图便是 vSAN 故障域的一个简单示意。vSAN 中有个词叫 FTT （Fault to Tolerance），意为最大允许同时故障多少台主机。FTT 决定的是虚拟机数据保护级别，也决定了一个集群所需的最小数量，一个集群中主机数量>=2N+1，N=FTT的值。
2、上面提到每台主机需要 RAID 卡将多个硬盘连接起来，也需要至少一个 SSD 和一个 HDD。SSD 只做读写缓存，从经济的角度看，不可能每个 HDD 都配置一块 SSD，需要多个 HDD 共享一块 SSD的资源。
在 vSAN 中，有了磁盘组这一概念，磁盘组是个逻辑的组，用于让多块 HDD 共享一个 SSD。
所以 vSAN 磁盘组和 RAID 组完全不是一个概念，数据是按照故障域为单位自动存储的，不能手动选择保存在哪台主机，更不能选择保存在哪个磁盘组。
vSAN 规定每个磁盘组最少需要一块SSD+一块HDD，最多一块+7块HDD。每台主机不能多于 5 个磁盘组。
让多块 HDD 共享一个 SSD 虽然节约成本，但也有一定风险，比如万一 SSD 故障，整个磁盘组的数据均会处于无法访问的情况，因此一般建议使用多个磁盘组分散数据，减少此种故障带来的影响。
举例：
集群1：每主机一个磁盘组，由1块400G SSD + 4块800G HDD 组成
集群2：每主机两个磁盘组，每磁盘组由1块200G SSD + 2块 800G HDD 组成
一旦集群1的一个 SSD 故障，vSAN 存储池会失去 3.2T 裸容量。
一旦集群2的一个 SSD 故障，vSAN 存储池会失去 1.6T 裸容量。
区分服务：
只要存在不同类型的业务，必然存在区分服务。
对于传统存储而言，服务的区分是存储卷级别的。一个存储卷的底层使用 RAID 10，上层业务获得的存储资源便是 RAID 10的保护级别和性能；一个存储卷的底层使用 RAID 5，上层业务获得的存储资源便是 RAID 5 的保护级别和性能。
1、
如前面在故障域中提到的，使用 vSAN 来保证数据在单节点故障时不丢失，至少需要三个节点。
如果要让数据在双节点故障时依然可以访问（即 FTT=2），数据应该怎么保存？
此时或许有人抢答，数据一分三，加一个仲裁，保存在四个节点上，如下图所示：
然而很可惜，这样的架构存在脑裂的风险，假如主机刚好两两隔离，那无法判断哪两个主机上的数据才是活动的，哪两台主机的存储资源需要被暂停。
因此可以通过加入一个见证节点来避免脑裂的发生（在实际情况中数据存储并不一定完全按照下图执行）。
实现下图的冗余级别，只需要修改虚拟机的存储策略，将 FTT=1 改为 FTT=2 即可。
2、
vSAN 通过存储策略来给不同的对象区分不同的服务。
例如：
给虚拟机 1 设置存储策略 A（ FTT=1，不预留缓存，限制 IOPS 为100）
给虚拟机 2 设置存储策略 B（FTT=2，预留 10% 的 SSD 缓存，不限制 IOPS）
Wait！上面提到一个词，对象（Object），什么是对象呢？
一个文件，例如 vmdk ，在 vSAN 中便是一个对象；
一个快照文件是一个对象；
虚拟机 swap 文件是一个对象；
虚拟机一般都会有一个文件夹存放与其相关的 vmx 文件、日志文件等，这个文件夹(VM home)在 vSAN 下也是一个对象。
可以理解为，在 vSAN 的世界中，一个虚拟机由多个对象组成。
对象并不是最小单位，对象由多个组件（Component）组成。一个对象如何变成多个组件便是由存储策略去决定的。
每个 Component 有大小限制，最大为 255G，因此大于 255G 的 Object 会被强制拆分成多个 Component。
至此，vSAN 主要的实现原理基本讲完了。
更多关于 vSAN 的知识，建议看看vSAN 相关的资料，也全放在了这里，尤其是里面的 vSAN Design Guide。
vSAN 具体如何配置？可以使用电脑打开下面的 Demo，按照指引一步步去创建 vSAN。
http://archive.halfcoffee.com/demo/vsan-demo.html
04
—
vSAN FAQ
下面记录一些 vSAN 常见的问题：
1、一个 vSAN 集群允许创建多个Datastore吗？
不能，每个 vSAN 集群只能有一个 Datastore，通过存储策略来为不同业务分发不同的保护策略。
2、不同速度、接口的 HDD 和 SSD 可以混用吗？
不能，最佳实践要求一个集群所有主机的硬件配置相同，如果是不同批次的硬件采购，尽量做到硬件性能差异很小。
以及，vSAN 好歹是个企业级的存储，这样配真的好吗？
3、可以指定将数据存放在哪个主机或磁盘组吗？
不能，vSAN 分布式存储的数据保存在哪里由 vSAN 来控制，请忘记传统的存储管理方式。
4、vSAN 支持全闪模式和混合模式，一个集群可以同时使用这两种模式吗？
不能，一个集群只能使用一种配置模式，且只能有一个 Datastore。
5、vSAN 环境中，本地的虚拟机会优先保存在本地的磁盘中吗？
不会。
6、vSAN 一定要使用单独的万兆交换机吗？
最佳实践推荐使用单独的万兆交换机，将存储流量和业务流量做一区分。
7、可以查看 vSAN 每个磁盘中保存的数据吗？
可以通过 vCenter 查看每个虚拟机的每个文件保存到了哪些磁盘，但是不能查看每个磁盘上具体有什么数据。
8、vSAN 的配置在 vCenter 中进行，vCenter 坏了会影响 vSAN 吗？
同 vSphere 管理一样，vCenter 只是一个管理角色，一旦 vSAN 创建好，vCenter 故障不会影响 vSAN 的使用。
9、vSAN 需要配置组播吗？
早期的 vSAN 版本中，所有主机之间通信会用到组播这种网络技术，一般如果vSAN VMkernel 网络在同一个网段，这时候只需要给交换机开启 IGMP Snooping 即可（NSX从入门到精通(20)：一篇文章让你读懂网络-上篇一文中有提到这项技术）。
如果是 vSAN 双活场景，会有两组 vSAN 机器分别在不同数据中心，vSAN VMKernel 网络是两个网段，这时候通信需要给沿途交换机配置组播路由（PIM协议）。
vSphere 6.5 以后版本搭配的 vSAN 只需要保证 IP 可达即可，不再需要配置 IGMP Snooping 或者 PIM。
05
—
总结
如果按照本文的讲述顺序，你会发现 vSAN 似乎很简单，然而稍微深入一下会有很多小知识。
前面提到一句话，企业级的安全+消费级的简单。
vSAN 在使用和操作层面，确实做到了极简，正常情况下在 vSphere 上开启 vSAN 功能只需要几分钟时间。
为了让 vSAN 更稳定可靠，vSAN 后端考虑了很多故障场景，通过技术手段避免发生故障时数据丢失。
vSAN 区别于其他分布式存储的重点是：vSAN 是基于存储策略的管理，策略可以下发给每个虚拟机的 vmdk 文件，非常之灵活，变更策略也非常简便。
也正是因为这个特点，使得 vSAN 特别适合于云计算，管理员不再需要管理多个存储池，设定非常复杂的关联关系，只需要根据业务类型配置不同的存储策略即可。
在扩展方面，vSAN 存储容量和性能可以随着节点数的增加而增加，vSAN 最大支持 64 台 ESXi 作为一个存储集群（64 也是 vSphere 集群支持的最大主机数）。
笔者曾经接触一个项目，6台双路服务器，每台服务器配置 24 块 2T HDD盘，4块 nvme SSD，加起来裸容量达 260+ T，而这仅仅占用了一个机柜的空间。
在应用场景方面，vSAN 能够满足任何虚拟化的存储需求。
vSAN 有一个很好用的场景，存储双活。相信基于前面的讲解，下图很容易理解吧？
-
NSX 从入门到精通-网络篇
-
NSX 从入门到精通-安全篇
“
有一天，同事突然说了一句话”你写的文章很好，但我看到5就看不下去了”。这时，我才意识到，并不是每个人都适合阅读系列的所有文章，我欠大家一个大纲，需要告诉大家哪些人应该看哪些内容。
”
截止目前，NSX 从入门到精通系列已经完成12篇。
写这个系列的原因比较简单：1、工作中会接触很多 NSX 项目；2、生态圈缺少对 NSX 的“正确”认识；3、相比 VMware 其他热门产品，NSX 非官方资料可谓少之又少。
似乎没有一个特别好的路径去了解 NSX 为什么好，好在哪里，除了熟知的安全外还能做什么，以及，最重要的，对未来和市场的改变。
与其等着一个称心的资料出现，不如自己去打造一份。那就立志长远，从零做起。
NSX 从入门到精通也是个很随意起的名字，一方面，这个名字代表了连续，可以将一个话题拆分成很多小模块去写，足够细，也就可以达到“精通”的地步；另一方面，是想直接通过标题就传达最终目标：这个系列=你需要的所有 NSX 资源。
NSX 从入门到精通系列面向对象是所有对 NSX 感兴趣的人，而针对不同人，可以读的内容并不一样。
大致来说，NSX 从入门到精通会包含四部分内容：
1、产品相关的背景介绍，功能简介（1~4，20~21）
2、产品相关的技术实现，操作（6~8）
3、产品相关的使用场景（5、9、10、11、网络部分待定）
4、最佳实践、排错（预计25+）
而从模块来说，暂分两大块：
1、NSX 安全：NSX 自身的安全、NSX 第三方安全解决方案（4~19）
2、NSX 虚拟网络：软件实现的全功能虚拟网络（20-待定）
对于销售人员，只需要了解产品的背景、功能、使用场景等；
对于售前人员，需要了解产品的背景、功能、使用场景、最佳实践等；
对于售后人员，最关注的可能是技术实现、操作、最佳实践、排错等内容。
因此哪些人该读那些内容，应该挺清晰吧！
除了学习，这些文章还能做什么？
经常有人会要一些产品的设计方案或者实施方案，这个系列便可以是不错的素材，直接复制粘贴，选用不同的标题就能代表不同的内容。
举个栗子：第5篇讲了 NSX 的安全转型，而转型前的架构可以=现有架构，转型后便是 NSX 的架构和价值；
再举个栗子：实施方案，包含设计和一些操作，6~8便包含了这部分内容。
这个系列，也可以作为 PPT 素材，一个 PPT 的产生=思路+素材，这个系列本身以及每个文章都会有自己的思路，文字和图片等于素材，距离一个 PPT 的诞生只剩下组织编排。
最后，还有一个潜在的价值，用于宣传。
实际会有很多 NSX 最终用户会在后台咨询一些 NSX 相关的问题，我相信产品再好，如果没有人知道能干什么，怎么用，那也会慢慢走出市场视线，所以，非常鼓励各位能帮助转发你觉得有价值的内容，分享给我们“潜在”的用户。
公众号后台的留言功能是开放的，也欢迎大家留言，可以咨询一些产品问题，也可以说出你的需求，我会寻找资源以文章的形式发布出来。
-
写 NSX PPT 就是拿很多素材然后排列组合...
现在经常会给一些合作伙伴做 NSX 的培训，听众可能是销售，售前或技术，每次都要根据听众来多多少少修改一下PPT的内容，但基本大的内容模块都是确定的，像下面一样，分为五部分内容：
第一部分，一般都是背景介绍，对于NSX而言，重要的几个点就是：
- 它的前身：NSX 发布于 2013 年，其前身是一家名叫 Nicira 的公司的产品，而Nicira 的创始人 Martin Casado 被称为 SDN 之父，是 Openflow 标准的创始人之一，也参与了 Openstack 平台网络模块的开发；
- NSX 市场情况 ：目前 NSX 在国内已经有 450+ 多家客户，客户涉及电信、教育、医疗、金融、事业单位、制造业等诸多行业；
- NSX 支持非常多的平台，例如 vSphere、KVM、公有云、容器等技术，在 vSphere 平台上可以和其他 VMware 解决方案集成；
- NSX 在安全方面非常开放，有着众多的合作伙伴来提供数据中心完整的安全解决方案。
第二部分，会介绍下当前数据中心的一些问题。
其实这部分重点是要凸显软件定义的概念，数据中心有三大件：计算、存储和网络，计算资源早在十几年前 VMware 推出第一款商用的服务器虚拟化软件时，就已经被软件定义了。
软件定义存储出现时间不长，但增长率特别快，其原理也大多数是把多台服务器本地硬盘通过软件糅合起来，做一个虚拟存储池给虚拟机提供服务。到这里，可能会着重提一下vSAN，因为 vSAN 是唯一一个把存储策略和虚拟机关联在一起的软件定义存储，其他的也就是对传统存储管理和使用方式的一个克隆。
最后，才到软件定义的网络。
有点跑题了，或许就直接介绍一下当前数据中心存在的问题吧。
现在很多数据中心的问题是由于传统网络架构的复杂导致的，比如厂商众多、协议众多、每台设备都需要独立配置。这些在管理和使用时都有诸多问题。所以有人画了张图，是说物理网络在拖后腿：
传统数据中心网络存在的问题大致可以汇总如下：
- 网络的分区导致虚拟化资源池的分区，造成整体资源池利用率下降；
- 传统基于硬件的安全不够细化，存在安全漏洞；
- 传统安全设备基于 IP 的配置方式可读性太差，不便于运维管理；
- 数据中心内有 80% 的流量为东西向流量，而这 80% 流量都需要经过物理交换机绕一圈，造成“发卡弯流量”；
- 云管理平台很难接管硬件网络设备，实现网络的统一配置；
- 设备纷杂，监控难度高，管理难度高，经常出现误操作导致的网络故障。
对应的，每个问题后面都会有一两张图来说明 NSX 的解决方案：
- NSX 有个技术叫微分段，可以在一个虚拟化池里面进行非常细的安全隔离，打破基于硬件防火墙的安全边界；
- NSX 微分段防火墙的生效位置是每个虚拟机的每个网卡，实现最细颗粒度的安全管控；
- NSX 可以基于名称、属性、标签等配置安全策略；
- NSX 将交换、路由和安全全部做成了分布式，不再有发卡弯流量；
- NSX 提供标准的网络和安全功能，提供开放 API，NSX 之上为虚拟机或者云平台提供标准的网络接口，NSX 之下和各种硬件网络做对接，屏蔽了硬件网络架构的复杂性；
- NSX 全图形化配置、监控界面，极简设计，只要不手残不会出现误操作。
第三部分，简单介绍下 NSX 的组件：
第四部分是个重点，介绍 NSX 的三大场景，为了更加生动形象，每个场景都有一些小视频来演示，表达 NSX 强大且好用：
第五部分，则是一些经验分享，会谈谈成功的 NSX 项目，讲讲曾经客户遇到的问题，以及 NSX 如何解决，最终客户和代理商双方均收获了什么。
再最后，分享一点干货，比如一些学习资源：
通常来说，这么一个 PPT 就够应付大部分的交流了，不过也有例外，比如客户对 NSX 安全的使用、NSX 的设计、NSX 多中心场景的建设等内容感兴趣，好在这些话题比较常见，我也有一些素材的积累，NSX 安全这块也已经写在了公众号里。
不过最近碰到一个客户要交流 SDN，这个还真是少数，为了云平台而去考虑 SDN 方案。
思来想去，觉得需要讲四个话题：
但是在开始这四个话题之前，必须得提一下软件定义数据中心。
因为现在有非常多的热门技术，像容器、大数据、人工智能等等，或许个人感觉不到什么，但是对于企业 CIO 而言，这些带来的冲击很大。
因为，在这些概念背后，他们面对的是这样的数据中心
其实解决办法很简单，就是软件定义的数据中心。
软件有着更新快、成本低、实现方便等诸多优点，前面提到的每个热门技术都是基于软件实现的，那数据中心只有通过软件定义才能跟得上发展节奏。
然后开始那四个话题。
客户既然提到了 SDN ，必然是了解过 SDN 的解决方案，这时候有一个不好的地方就是其他很多 SDN 都是基于硬件的 SDN，而 NSX 是纯软件实现的，功能和架构上直接对比没有多少意义。
不过将 SDN 和 NSX 拿出来对比有一些有利的地方，比如前面提到的 NSX 的起源，NSX 的前身 Nicira 创始人是 SDN 之父，NSX 继承了 SDN 的架构和理念，论历史和背景，NSX 一点不差。
然后，要突出 NSX 的不同，那就是在架构和功能上的不同：
NSX 不仅仅是一个网络虚拟化产品，更是一个集各种网络服务、安全服务、网络可视化为一体的平台，而且是个很开放的平台。
NSX 功能虽然很多，但使用非常简单。
第二部分，标题叫“NSX需要解决的问题”，其实内容等于前面说的“传统数据中心网络的挑战和解决之道”。当然在讲述顺序上需要调整一下：
比如首先需要提一下目前的一些新技术以及具体的网络层面的应对方案。
第二、提及一下基于硬件的网络很难统一控制。
第三、提一下传统数据中心的安全架构存在漏洞，在这部分，需要讲一下 NSX 的安全是可以和云管理平台集成实现自动化安全的。
第四、作为一个完整的虚拟化网络和安全平台，开放接口以及其生态圈需要说明。
第五、这个是很多客户比较关心的，成本问题。NSX 可以在当前的物理网络架构上搭建，不需要更换设备，可以有效保护资产。
剩下的一些内容基本就是前面提到的发卡弯的问题、管理的问题、运维的问题等等。
第三部分是一个重点，因为客户目前还不确定使用哪个云管理平台，所以需要介绍下 NSX 与云管平台对接的内容。
首先，说明一下目前其他客户的云平台和网络都是怎么建设的，比如 39% 的用户没有让云管理平台和 NSX 深度集成，34%的用户使用 VMware vRealize Automation 与 NSX 进行了集成，剩下的比较少的都是第三方云平台的集成。
其实这个数据也比较好理解，通常很多企业云平台规模不大，所以在不深度集成 NSX 时管理起来没多大问题；而稍大规模的都会使用 vRA 进行集成，可以开箱即用，省去不少研发和对接的工作；最后的，可能企业有实力去开发和定制 Openstack，于是用的其他云平台和 NSX 对接。
不过，无论什么云平台，NSX 都是有开放的 API 让第三方平台去对接：
NSX REST API 手册非常详细，NSX 的功能都可以通过 API 来配置。
最后一部分，再讲讲 NSX 在数据中心的三大应用场景，介绍下其他客户如何去使用 NSX。
安全部分，讲三个话题：
- NSX 在数据中心的安全隔离；
- NSX 与第三方安全产品的集成；
- NSX 在桌面虚拟化中的安全隔离；
自动化部分，展示一下 vRA 与 NSX 集成后实现的三层应用自动部署：
多数据中心部分，讲解一下双活、灾备、多中心资源池的建设：
最后，总结一下 NSX 的架构和优点：
嗯，这些内容足够讲一个小时了吧，到时候再准备些 Offline Demo 以及 Openstack 对接相关的 PPT 做备份。
想想整个 PPT 的制作过程，真的是拿了一大堆素材，改下名字，排下顺序，就出炉了… 😂😂
文中提到的一些资料、场景等可以参看过往文章：
-
DNS 委派配置
摘要
今天在学习GSLB时，想到一个问题，就是如果企业内部有些服务器对互联网用户提供服务，那么必然牵扯到互联网域名如何对应到本地的DNS服务器。按照F5 GSLB的文档，一般是在互联网域名管理端配置NS记录，将子域名委派(delegation)给GSLB。
经过测试，有两种办法可以将DNS的解析转移到本地的GSLB上。一种是上面说的配置子域名的NS记录，一种是直接将域名的DNS指定为本地的DNS server，下面详细说说配置过程。
修改子域名的NS记录
环境情况：
1、在云端自建一个DNS server，环境使用Centos+BIND，可以通过域名mi.halfcoffee.com访问到此DNS 服务器。下图为此DNS 服务器上配置的解析配置：
-
一次 VSAN 误操作后的恢复纪实
摘要
从VSAN 6.6 开始，vSphere支持在部署VCSA时创建VSAN，然后将需要部署的VCSA存放在VSAN存储上。在此之前如果要部署VSAN，必须先找个服务器本地硬盘装好VCSA，然后再创建VSAN，最后再将vCenter迁移回VSAN环境。
按照VMware最佳实践，管理集群和计算集群需要分开，但很多小型环境受资金限制仍然会将所有vSphere管理组件和业务虚拟机一起放到VSAN运行，这样如果存储出现问题，管理虚拟机也会故障，未来不方便收集日志或者修复(这里要重点提的是：VSAN目前没有因为软件问题导致数据丢失的案例，大家听过的VSAN故障均为误操作或者硬件兼容性问题，所以大家大可放心去(正常)使用)。
今天要说的就是一个因为误操作导致VSAN存储不可用，而所有管理虚拟机均不可访问的恢复过程。这个恢复过程可以帮助展示VSAN的一些工作原理，让大家更熟悉VSAN，避免在重要环境发生误操作。生产环境还是建议走正规渠道开CASE，不要自己琢磨怎么修复，以免误操作数据丢失。
事件起因
VSAN环境由3台ESXi组成，每台服务器双万兆给VSAN用（vDS），双VSAN给业务虚拟机用（vDS），管理网络使用千兆（vSS），vCenter 运行在VSAN上。因为误操作，导致 VSAN vDS 的 Uplink 没有关联任何物理接口，导致VSAN网络故障，进而所有虚拟机处于无法访问状态，但可以登陆每台ESXi的 web UI。
故障现象如下图：
虚拟机状态为Invalid，无法进行任何的管理
VSAN 存储的容量有问题，只有单个ESXi主机的容量（正常应该为36GB）
修复思路
在检查环境后，确定是主机之间VSAN网络通信故障，登陆任意一台ESXi主机均不能ping通其他主机的 VSAN 地址：
使用
esxcli vsan cluster get命令看到每台ESXi主机上VSAN Cluster 成员只有自己，没有其他两台机器
登陆ESXi，发现已经无法管理VSAN VDS，例如给其添加Uplink操作：
可以看到每台主机有VSAN的VMkernel，且类型标记为 vsan。
从VSAN 6.6开始，所有VSAN之间的通信全部采用单播模式，单播相对于组播的优势是组网简单，但是缺点是需要一个中心节点来让所有节点相互知晓，这个节点就是vCenter，简而言之，在创建VSAN 6.6时，vCenter必须处于可用状态。但是，vCenter只是自动地让VSAN节点之间相互知晓，我们可以手动为VSAN每个节点指定其他邻居。VSAN 6.6 可以通过命令
esxcli vsan cluster unicastagent list来查看此ESXi主机的VSAN邻居有哪些。下图中vsan-2的邻居有两个，分别为 10.0.0.1和10.0.0.3，且都启用了Unicast，NodeUUID也可以看到。
对比vsan-1的cluster信息，可以看到此处的NodeUUID就是cluster get命令获取到的Local UUID。
- [Series:4/4]nsx-t powercli script to get loadbalancer infos
- [Series:3/4]nsx-t powercli script to batch create T1 router ports
- [Series:2/4]nsx-t powercli script to batch create logical switches
- [Series:1/4]nsx-t powercli script to batch create firewall rules
- Operationalize Your World 中文版-2
- Operationalize Your World 中文版-1
- vCenter 被 NSX 防火墙阻断后怎么办?
- NSX高阶操作：利用 API 控制管理员可访问范围
- NSX从入门到精通(11)：NSX 微分段的使用场景之云安全
- 如何卸载趋势无代理防病毒