C#项目打包并自动安装SQL数据库

应一位网友的需求 并修正了MVP李洪根 NET平台下WEB应用程序的部署(安装数据库和自动配置) 中的osql用法错误 已测试通过

一) 创建部署项目 在 文件 菜单上指向 添加项目 然后选择 新建项目 在 添加新项目 对话框中 选择 项目类型 窗格中的 安装和部署项目 然后选择 模板 窗格中的 安装项目 在 名称 框中键入 setup 单击 确定 关闭对话框 项目被添加到解决方案资源管理器中 并且文件系统编辑器打开 在 属性 窗口中 选择 ProductName 属性 并键入 信息管理系统

二) 将 主程序 项目的输出添加到部署项目中 在 文件系统编辑器 中 选择 应用程序文件夹 在 *** 作 菜单上 指向 添加 然后选择 项目输出 在 添加项目输出组 对话框中 选择 项目 下拉列表中的 你的程序 单击 确定 关闭对话框 从列表中选择 主输出 和 内容文件 组 然后单击 确定

三) 创建安装程序类 在 文件 菜单上指向 新建 然后选择 项目 在 新建项目 对话框中 选择 项目类型 窗格中的 Visual Basic 项目 然后选择 模板 窗格中的 类库 在 名称 框中键入 installDB 单击 打开 关闭对话框 从 项目 菜单中选择 添加新项 在 添加新项 对话框中选择 安装程序类 在 名称 框中键入 installDB 单击 确定 关闭对话框 详细代码附后

四) 创建自定义安装对话框 在解决方案资源管理器中选择 setup 项目 在 视图 菜单上指向 编辑器 然后选择 用户界面 在用户界面编辑器中 选择 安装 下的 启动 节点 在 *** 作 菜单上 选择 添加对话框 在 添加对话框 对话框中 选择 许可协议 对话框 然后单击 确定 关闭对话框 在 添加对话框 对话框中 选择 文本框 (A) 对话框 然后单击 确定 关闭对话框 在 *** 作 菜单上 选择 上移 重复此步骤 直到 文本框 (A) 对话框位于 安装文件夹 节点之上 在 属性 窗口中 选择 BannerText 属性并键入 安装数据库 选择 BodyText 属性并键入 安装程序将在目标机器上安装数据库 选择 Edit Label 属性并键入 数据库名称: 选择 Edit Property 属性并键入 CUSTOMTEXTA 选择 Edit Value 属性并键入 dbservers 选择 Edit Label 属性并键入 服务器名: 选择 Edit Property 属性并键入 CUSTOMTEXTA 选择 Edit Value 属性并键入 (local) 选择 Edit Label 属性并键入 用户名: 选择 Edit Value 属性并键入 sa 选择 Edit Property 属性并键入 CUSTOMTEXTA 选择 Edit Label 属性并键入 密码: 选择 Edit Property 属性并键入 CUSTOMTEXTA 选择 Edit Visible Edit Visible 和 Edit Visible 属性 并将它们设置为 true

五) 创建自定义 *** 作 在解决方案资源管理器中选择 setup 项目 在 视图 菜单上指向 编辑器 然后选择 自定义 *** 作 在自定义 *** 作编辑器中选择 安装 节点 在 *** 作 菜单上 选择 添加自定义 *** 作 在 选择项目中的项 对话框中 双击 应用程序文件夹 选择 主输出来自 installDB（活动） 项 然后单击 确定 关闭对话框 在 属性 窗口中 选择 CustomActionData 属性并键入 /dbname=[CUSTOMTEXTA ] /server=[CUSTOMTEXTA ] /user=[CUSTOMTEXTA ] /pwd=[CUSTOMTEXTA ] /targetdir= [TARGETDIR]\

附:/targetdir= [TARGETDIR]\ 是安装后的目标路径 为了在installDB类中获得安装后的路径 我们设置此参数

六) 添加文件 将SQL Server备份成文件DB dat添加到 setup 项目(在企业管理器中右击数据库 >所有工作 >备份数据库 备份成一个文件 取名为DB dat) 将安装文件LisenceFile rtf添加到 setup 项目 在用户界面编辑器中 选择许可协议 设置LisenceFile属性为LisenceFile rtf文件 一般会自动将依赖项添加到 检测到的依赖项 如果没有 那么我们要手动将其加入步骤 ） Crystal_Managed m （如果有水晶报表） dotnetfxredist_x m 一定是必须的） （如果有引用其他的dll） 如果使用了水晶报表 手动加入要包含的文件 项目 >添加 >合并模块（添加你的程序文件） (包括dotNetFramework和MDAC ) 位于 C:\Program Files\Common Files\Merge Modules\ 下 为必要的 具体功能如下 （托管组件 MSM 处理所有托管组件的分发 其中包括 Windows 窗体查看器 Web 窗体查看器和所有 Crystal Decisions 命名空间） Crystal_Managed m Crystal_Managed _chs m （对于使报表运行所需的所有其他文件 由数据库访问 MSM 处理其分发 其中包括数据库 导出和图表驱动程序 ） Crystal_Database_access m Crystal_Database_access _chs m （KeyCode MSM 处理 Crystal Decisions 密钥号码的安装 注意是添加合并模块 否则没有 MergeMouduleProperties 属性） Crystal_regwiz m （如果报表文件使用了 ADO NET 的 dataset 数据集对象 那么 VC_User_CRT _RTL_X _ m 和 VC_User_STL _RTL_X _ m 模块也必须包含在安装工程中 而且这两个模块的文件安装属性的 Module Retargetable Folder 项必须修改成为系统目录） VC_User_CRT _RTL_X _ m VC_User_STL _RTL_X _ m (很多人经常出现查询错误 不妨加上这个) 打开解决方案 >右键点击Crystal_regwiz m 的属性 在 MergeMouduleProperties 里的 License Key 填入 AAP GKS GDE DS（这个是你生成Crystal Report是用到的注册号的密码！）

七) 打包时加入卸载功能 方法一: 在打包项目中添加文件msiexec exe(一般可在c:\windows\system \下找到) 在文件系统视图中选择应用程序文件夹 在msiexec exe上按右键 选择创建快捷方式 重命名快捷方式为 卸载 更改此快捷方式的Arguments 为 /x {产品id} 产品id的值为打包项目的ProductCode属性值 方法二:(推荐) 先生成安装包 记下ProductCode(选择解决方案资源管理器根目录如setup 再查看属性标签 不是右键中的属性) 下面要用到 用建立一个新的控制台程序uninst exe文件 power by: landlordh for xp Module uninstall Sub Main() Dim myProcess As Process = New Process If System Environment OSVersion ToString IndexOf( NT ) Then myProcess Start( msiexec /X{ B D A C AB B FB } ) 改为自己的ProductCode End If myProcess Close() End Sub End Module 将控制台程序BIN目录的exe文件加入到打包程序文件中 在程序组创建uninst exe的快捷方式

附 installdb vb类 要添加引用 nfiguration install dll :

Imports System ComponentModel Imports System Configuration Install

Public Class Installer Inherits System Configuration Install Installer

#Region 组件设

计器生成的代码

Public Sub New() MyBase New()

该调用是组件设计器所必需的 InitializeComponent()

在 InitializeComponent() 调用之后添加任何初始化

End Sub

Installer 重写 dispose 以清理组件列表 Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean) If disposing Then If Not (ponents Is Nothing) Then ponents Dispose() End If End If MyBase Dispose(disposing) End Sub

组件设计器所必需的 Private ponents As System ComponentModel IContainer

注意: 以下过程是组件设计器所必需的 可以使用组件设计器来修改此过程 不要使用代码编辑器来修改它 Private Sub InitializeComponent() ponents = New System ComponentModel Container End Sub

#End Region

Public Overrides Sub Install(ByVal stateSaver As System Collections IDictionary) MyBase Install(stateSaver) If Not InstallDB() Then 失败 反安装 Me Uninstall(stateSaver) Exit Sub End If DeleteFile(String Format( { }DB dat Me Context Parameters Item( targetdir ))) End Sub

lishixinzhi/Article/program/net/201311/13045

MySQL在互联网应用中已经遍地开花，但是在银行系统中，还在生根发芽的阶段。本文记录的是根据某生产系统实际需求，对数据库高可用方案从需求、各高可用技术特点对比、实施、测试等过程进行整理，完善Mysql高可用方案，同时为后续开展分布式数据库相关测试做相应准备。

存储复制技术： 传统IOE架构下，常用高可用方案，靠存储底层复制技术实现数据的一致性，优点数据安全性有保障，限制在于是依赖存储硬件，实施成本较高。

keepalived+双主复制： 两台MySQL互为主从关系，即双主模式，通过Keepalived配置虚拟IP，实现当其中的一台数据库故障时，自动切换VIP到另外一台MySQL数据库，备机快速接管业务来保证数据库的高可用。

MHA： MHA部署在每台mysql服务器上，定时探测集群中的master节点，当master出现故障时，它可以自动将最新的slave提升为新的master，然后将所有其他的slave重新指向新的master，优点在最大程度保证数据的一致性的前提下实现快速切换，最少需要3台服务器，存在数据丢失的可能性。

PXC： Percona eXtra Cluster是Percona基于galera cluster封装的集群方案。不同于普通多主复制，PXC保障强一致性和实时同步，故障切换更快。但是也需要3个节点，配置相对复杂，对性能也稍有影响。

除了上述方案外，还有MMM、Heartbeat+DRBD等高可用方案，此处不做详细介绍。

综合评估下，本次实施采用了 keepalived+mysql双主实现数据库同城双机房的高可用。MySQL版本为： 5721。 *** 作系统：Red Hat Enterprise Linux Server 73。

配置过程如下：

Mysql-master1: IP地址1 --以下简称master1

Mysql-master2: IP地址2 --以下简称master2

Mysql-vip : VIP地址 --应用连接使用

Mysql复制相关概念描述：

1、 Mysql主从复制图示：

2、 Mysql主从复制过程描述：

（1）master记录二进制日志：在每个事务更新数据完成之前，master在二进制日志记录这些改变。MySQL将事务写入二进制日志。在事务写入二进制日志完成后，master通知存储引擎提交事务。

（2）slave将master的binarylog拷贝到自己的中继日志：首先，slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事务，如果已经同步了master，它会睡眠并等待master产生新的事件。I/O线程将这些事务写入中继日志。

（3）SQL slave thread处理该过程的最后一步：SQL线程从中继日志读取事务，并重放其中的事务而更新slave的数据，使其与master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。

主主同步就是两台机器互为主的关系，在任何一台机器上写入都会同步至备端。

为了便于后续数据库服务器的扩展，且在整个复制环境中能够自动地切换，降低运维成本，引入了当前主流的基于Mysql GTID的复制特性，工作原理及优缺点简介如下。

3、 GTID工作原理简介：

（1） master更新数据时，会在事务前产生GTID，一同记录到Binlog日志中。

（2） slave的I/O线程将变更的binlog写入到本地的relay log中。

（3） slave的sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。

（4） 如果有记录说明该GTID的事务已经执行，slave会忽略。

（5） 如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。

（6） 在解析的过程中会判断是否有主键，如果有就用索引，如果没有就用全部扫描。

4、 GTID优点：

（1） 一个事务对应一个唯一的ID，一个GTID在一个服务器上 只会执行一次。（2） GTID是用来替代传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置。

（3） 减少手工干预和降低服务故障时间，当主机宕机之后会通过软件从众多的备机中提升一台备机为新的master。

5、 GTID也存在一些限制：

（1） 不支持非事务引擎。

（2） 不支持create table … select 语句复制(主库直接报错)。

（3） 不允许一个sql同时更新一个事务引擎表和非事务引擎表。

（4） 在一个复制组中，必须要求统一开启GTID或者是统一关闭GTID。

（5） 开启GTID需要重启(57版本除外)。

（6） 开启GTID后，就不再使用原理的传统复制方式。

（7） 不支持create temporary table 和 drop temporary table语句。

（8） 不支持sql_slave_skip_counter。

前置条件：

主备两个节点使用行内统一的安装部署脚本安装mysql5721介质(略)

Master1端创建应用的数据库(略)

1、 修改MySQL配置文件

参考相关配置规范，分别设置master1、master2的mycnf文件，

其中server-id参数设置为不同值;

由于后续keepalived会挂起VIP，应用通过VIP连接数据库，为了避免应用程序无法通过VIP访问，需将两个节点的bind-address参数注释掉；

2、 设置master1端自动半同步模式

Mysql的同步模式主要有如下3种：

a 主从同步复制：数据完整性好，但是性能消耗略高；

b 主从异步复制：性能消耗低，但容易出现不一致；

c 主从半自动复制：介于上述两种之间，既保持了数据的完整性，又提高了性能；

基于上述特性，建议采用半自动同步模式，由于后续要配置为双主模式，因此任一节点其角色既为master又为slave，因此相关的master/slave插件要同时配置，过程如下。

（1） 首先查看库是否支持动态加载(默认都支持)

（2） 主从库上分别安装插件

作为主库，安装插件semisync_masterso

作为从库，安装插件semisync_slaveso

（3） 安装完成后，从plugin表中能够看到刚刚安装的插件

（4） 分别打开主从库半同步复制

同时添加到各自的mycnf中，在后续数据库实例重启时自动加载该配置。

此时查看状态还没有启动

（5） 两个节点分别启动IO进程

（6） 查看半同步状态

3、 将master1设为master2的主服务器

（1）在master1主机上创建授权账户，允许在master2主机上连接

（2）将主库master1数据导出

（3）将mastersql传输到master2上并导入

（4）在master2端将master1设置为自己的主库，并开启slave功能

在master2上查看slave状态

至此master1到master2的主从复制关系已经建立完成。

4、 将master2设为master1的主服务器

在master1上执行

在master1上查看slave状态

1、keepalived相关概念说明：

keepalived是集群管理中保证集群高可用的一个软件解决方案，其功能类似于heartbeat，用来防止单点故障

keepalived是以VRRP协议为实现基础的，VRRP全称VirtualRouter Redundancy Protocol，即虚拟路由冗余协议。

虚拟路由冗余协议，可以认为是实现路由器高可用的协议，即将N台提供相同功能的路由器组成一个路由器组，这个组里面有一个master和多个backup，master上面有一个对外提供服务的vip，master会发组播（组播地址为2240018），当backup收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master，这样的话就可以保证路由器的高可用了。

keepalived主要有三个模块，分别是core 、check和vrrp。core模块为keepalived的核心，负责主进程的启动、维护以及全局配置文件的加载和解析。check负责 健康 检查，包括常见的各种检查方式。vrrp模块是来实现VRRP协议的。同时为了避免出现脑裂，应关闭防火墙或者开启防火墙但允许接收VRRP协议。

2、keepalived的安装配置

（1）配置本地yum源，在master1和master2两台服务器上安装keepalived的相关依赖包Kernel-devel/openssl-devel/popt-devl等

配置指向rhel-75iso的yum本地源，步骤略

注意：如不知道keepalived需要哪些依赖包，可到下载后的源码解压目录下查看INSTALL 文件内容，安装需要的依赖包，源码安装任何一个软件都要养成查看源码包文档的习惯，比如INSTALL，README,doc等文档，可以获得很多有用的信息。

（2）在两台mysql上解压缩并编译安装keepalived

（3）master1、master2上分别配置keepalivedconf

注意上图红色字体中两个节点配置相同处及差异。

说明：keepalived只有一个配置文件keepalivedconf，里面主要包括以下几个配置区域：

· global_defs：主要是配置故障发生时的通知对象以及机器标识。

· vrrp_instance：用来定义对外提供服务的VIP区域及其相关属性。

· virtual_server：虚拟服务器定义

（4）同时两个节点上都需要添加检测脚本

作用：是当mysql停止工作时自动关闭本机的keeplived服务，从而实现将故障主机踢出热备组，因每台机器上keepalived只添加了本机为realserver，所以当mysqld正常启动后，我们还需要手动启动keepalived服务。

（5）分别启动两个节点的keepalived服务

检查两个节点keepalived启动进程

检查两个节点的vip挂载情况

（6）主备机故障切换测试

停止master2的mysql服务，看keepalived 健康 检查程序是否会触发脚本，自动进行故障切换，步骤略

查看master1节点的VIP挂载情况，验证是否实现了自动切换，步骤略

说明在master2服务器的mysql服务发生故障时，触发了脚本，自动完成了切换。

（7）现在我们把master2的mysql服务开起来，并且keepalived的服务也需要启动。

即便master2的mysql服务和keepalived服务都重新开启了，master1仍然是主master了，master2未对主master的权利进行抢夺，说明设置的nopreempt参数生效了，为了保证群集的稳定性，生产环境不允许抢占配置，只有当master1的mysql服务坏掉的时候，master2才会再次成为主master，否则它永远只能当master1的备份。（注：nopreempt一般是在优先级高的mysql上设置）

Sysbench是一个模块化的、跨平台、多线程基准测试工具，可用于评估数据库负载情况，通过sysbench命令配置IP地址、端口号、用户名、密码连接到指定的数据库db1中，创建多个表，并快速插入指定条数的记录，观察主备库同步效率

(1) 下载开源工具sysbench-041214targz，放置在相应目录下并解压

(2) 使用iso配置本地yum源并安装Sysbench如下的依赖包(步骤略)：autoconf/automake/cdbs/debhelper(>=9)/docbook-xml/docbook-xsl/libmysqlclient15-dev/libtool/xsltproc

(3) 编译sysbench

编辑配置文件/etc/ldsoconf中添加mysql lib目录/mysql/app/5721/lib，并执行命令ldconfig生效

(4) 执行sysbench压测

使用sysbench工具向主节点的db1数据库中创建5张表，并且每张表分别插入10万条记录

同时观察备机同步效率

几个重要的参数说明：

B、半自动同步模式、异步模式切换测试

(1) 检查主备同步状态，及同步参数设置

rpl_semi_sync_master_enabled参数表示启用半同步模式；

rpl_semi_sync_master_timeout参数单位为毫秒，表示主库事务等待从库返回commit成功信息超过10秒就降为异步模式，不再等待从库，等探测到从库io线程恢复后，再返回为半自动同步；

rpl_semi_sync_master_wait_no_slave参数表示事务提交后需要等待从库返回确认信息；

(2) 将slave的io线程停止

(3) 使用sysbench向master写入少量的数据，本例创建一张表，并插入10条记录，命令包装在1sh测试脚本中

通过记录的时间戳发现，master在等待了slave10秒无响应，自动切换为异步模式，将数据写入本地。

(4) Slave启动io线程，数据自动追平

至此MySQL主主复制配置完成，运行在半自动同步模式，通过keepalived实现Mysql的HA高可用。

上线后应符合统一的标准监控策略，添加备份协议对数据进行周期备份并保存到带库中，以及定期的数据恢复测试。

由于是靠keepalived实现的高可用，还应将如下资源添加到监控管理平台：

1、 对每台数据库主机的3个keepalived进程进行监控；

2、 对主备节点的io线程、sql线程工作状态进行监控；

请问stonys为什么要删我贴？U8 V10 用户手册难道只允许网站收费下载，不允许我免费分享吗？我的原则：我为人人，人人为我！请stonys回答! 查看原帖>>

麻烦采纳，谢谢!

以Kubernetes为代表的容器编排工具在应用开发部署领域起正发挥着颠覆性的变革作用。随着微服务架构的发展，从开发人员的角度来看，应用逻辑架构与基础设施架构之间开始解耦，这意味着开发者能够将精力更多集中在软件构建以及价值交付身上。

当管理Docker镜像的时候，Kubernetes也让实际应用变的十分便捷灵活。在利用Kubernetes进行容器架构的应用部署时，管理员们将在无需修改底层代码的前提下将其部署在任何位置——包括公有云、混合云乃至私有云。

虽然Kubernetes在扩展性、便携性与管理性等方面的表现都相当给力，但截至目前，它仍然不支持存储状态。与之对应的是，如今的大多数应用都是有状态的——换言之，要求在一定程度上配合外部存储资源。

Kubernetes架构本身非常灵活的，能够根据开发者的需求、规范以及实际负载情况，对容器进行随意创建与撤销。此外，Pod和容器还具有自我修复与复制能力。因此从本质上讲，它们的生命周期普遍非常短暂。

但是，现有持久存储解决方法无法支持动态的应用场景，而持久化存储也无法满足动态创建与撤销的需求。

当我们需要将有状态应用部署到其它基础架构平台，或者另一家内部或混合云供应商的环境中时，可移植性低下无疑将成为我们面临的巨大挑战。更具体地讲，持久化存储解决方案往往会锁定于特定云服务供应商，而无法灵活完成转移。

另外，云原生应用中的存储机制也相当复杂、难于理解。Kubernetes中的不少存储术语极易混淆，其中包含着复杂的含义与微妙的变化。再有，在原生Kubernetes、开源框架以及托管与付费服务之间还存在着诸多选项，这极大增加了开发人员在做出决定之前的考量与试验成本。

以下是CNCF列出的云原生存储可选方案：

我们首先从最简单的场景出发，即在Kubernetes当中部署一套数据库。具体流程包括：选择一套符合需求的数据库，让它在本地磁盘上运行，然后将其作为新的工作负载部署到集群当中。但是，由于数据库中存在的一些固有属性，这种方式往往无法带来符合预期的效果。

容器本身是基于无状态原则进行构建的，凭借这一天然属性，我们才能如此轻松地启动或撤销容器环境。由于不存在需要保存及迁移的数据，集群也就不需要同磁盘读写这类密集型 *** 作绑定在一起了。

但对于数据库，其状态必须随时保存。如果以容器方式部署在集群当中的数据库不需要进行迁移，或者不需要频繁开关，那么其基本属性就相当于一种物理存储设备。在理想情况下，使用数据的容器应该与该数据库处于同一Pod当中。

当然，这并不是说将数据库部署在容器中的作法不可取。在某些应用场景下，这样的设计完全能够满足需求。举例来说，在测试环境或者处理非生产级数据时，由于总体数据量很小，将数据库纳入集群完全没有问题。但在实际生产中，开发人员往往需要仰仗于外部存储机制。

Kubernetes到底是如何与存储资源彼此通信的？其利用的是控制层接口。这些接口负责将Kubernetes与外部存储相对接。接入Kubernetes的外部存储解决方案被称为“卷插件（Volume Plugins）”。正是有了卷插件的存在，存储资源才得以抽象化并实现可移植性。

以前，卷插件一般由核心Kubernetes代码库进行构建、链接、编译以及装载。这样就极大的限制了开发人员的发挥空间，同时也带来了额外的维护开销。因此，项目维护人员们决定在Kubernete的代码库上增加一些新的存储功能。

随着CSI以及Flexvolume的引入，卷插件如今可以在集群中直接部署，而完全无需更改代码库。

原生Kubernetes与存储

持久卷是由管理员负责配置的存储单元，它们独立于任何单一Pod之外，因此不受Pod生命周期的影响。

存储资源有两种使用方式：静态存储与动态存储。

实际上，静态定义的持久卷并不能适应Kubernetes的可移植特性，因为存储资源具有对环境的依赖性——例如AWS EBS或者GCE Persistent Disk。另外，手动绑定还需要根据不同供应商的存储方案修改YAML文件。

在资源分配方面，静态配置实际上也违背了Kubernetes的设计原则。后者的CPU与内存并非事先被分配好绑定在Pod或者容器上，而是以被动态形式进行分配。

通过简单的说明，相信大家已经了解了原生Kubernetes对外部存储资源的使用方式。当然，这里仅仅做出概括，实际使用场景中还有更多其它因素需要考量。

CSI——容器存储接口

下面来看容器存储接口（简称CSI）。CSI是由CNCF存储工作组创建的统一标准，旨在定义一个标准的容器存储接口，从而使存储驱动程序能够在任意容器架构下正常起效。

CSI规范目前已经在Kubernetes中得到普及，大量驱动插件被预先部署在Kubernetes集群内供开发人员使用。如此一来，我们就可以利用Kubernetes上的CSI卷来访问与CSI兼容的开放存储卷。

CSI的引入，意味着存储资源能够作为Kubernetes集群上的另一种工作负载实现容器化以及部署。

相关开源项目

目前，围绕云原生技术涌现出大量工具与项目。但作为生产场景中的一大突出问题，我们往往很难在云原生架构中选择最合适的开源项目。换言之，解决方案选项太多，反而令存储需求变得更难解决。

我们再看一次CNCF列出的云原生存储的可选方案：

下面我会分享一下当下流行的存储方案Ceph与Rook，还有Rancher开源的容器化分布式存储Longhorn。

Ceph

Ceph是一种动态托管、横向扩展的分布式存储集群。Ceph面向存储资源提供一种逻辑抽象机制，其设计理念包括无单点故障、自管理以及软件定义等特性。Ceph可以面向同一套存储集群分别提供块存储、对象存储以及文件存储的对应接口。

Ceph架构相当复杂的，其中使用到大量的底层技术，例如RADOS、librados、RADOSGW、RDB、CRUSH算法，外加monitor、OSD以及MDS等功能性组件。这里我们先不谈它的底层架构，关键在于Ceph属于一种分布式存储集群，这使得扩展更便利、能够在不牺牲性能的前提下消除单点故障，且提供涵盖对象存储、块存储以及文件存储的统一存储体系。

Ceph架构图

Rook

另一个有趣且颇具人气的项目是Rook，这是一项旨在将Kubernetes与Ceph融合起来的技术方案。从本质上讲，它将计算节点和存储节点放进了同一个集群当中。

Rook是一种云原生编排器，并对Kubernetes做出扩展。Rook允许用户将Ceph放置在容器内，同时提供卷管理逻辑以立足Kubernetes之上实现Ceph的可靠运行。Rook还使本应由集群管理员 *** 作的多种任务完成了自动化实现，其中包括部署、引导、配置、扩展以及负载均衡等等。

Rook自身不具备持久状态，也不需要单独管理。这，才是真正与Kubernetes设计原则相符的存储资源管理方案。

Rook凭借着将Ceph与Kubernetes协同起来的强大能力而颇受欢迎，在GitHub上获得近4000颗星，1600多万次的下载，并吸引到100多名贡献者，现已进入CNCF孵化阶段。

Longhorn

Longhorn项目是Rancher Labs推出的开源的基于云和容器部署的分布式块存储新方式。Longhorn遵循微服务的原则，利用容器将小型独立组件构建为分布式块存储，并使用容器编排来协调这些组件，形成d性分布式系统。

如今，基于云和容器的部署规模日益扩大，分布式块存储系统也正变得越来越复杂，单个存储控制器上的volume数量在不断增加。2000年代初，存储控制器上的volume数量只有几十个，但现代云环境却需要数万到数百万的分布式块存储卷。存储控制器变成了高度复杂的分布式系统。

Longhorn充分利用了近年来关于 如何编排大量的容器和虚拟机的核心技术 。例如，Longhorn并没有构建一个可以扩展到100,000个volume的高度复杂的控制器，而是出于让存储控制器简单轻便的考虑，创建了100,000个单独的控制器。然后，我们可以利用像Kubernetes这样的最先进的编排系统来调度这些独立的控制器，共享一组磁盘中的资源，协同工作，形成一个d性的分布式块存储系统。

Longhorn基于微服务的设计还有很多其他优势。因为每个volume都有自己的控制器，在升级每个volume的控制器和replica容器时，是不会导致IO *** 作明显的中断的。Longhorn可以创建一个长期运行的工作来编排所有live volume的升级，同时确保不会中断系统正在进行的 *** 作。为确保升级不会导致意外的问题，Longhorn可以选择升级一小部分volume，并在升级过程中出现问题时回滚到旧版本。这些做法在现代微服务应用中已得到广泛应用，但在存储系统中并不常见。希望Longhorn可以 助力于微服务在存储领域的更多应用。

结 语

对于实际应用层面出现的任何问题，最重要的自然是判断需求、设计系统或者选择适当的工具。同样的道理也适用于云原生环境。虽然具体问题非常复杂，但也必然会出现大量工具方案尝试解决。随着云原生世界的持续发展，我们可以肯定，新的解决方案将不断涌现。未来，一切都会更加美好！

以上就是关于C#项目打包并自动安装SQL数据库全部的内容，包括:C#项目打包并自动安装SQL数据库、基于MySQL双主的高可用解决方案理论及实践、用友U8 V10.0 IT部署方案(别再问支持什么 *** 作系统适用什么数据库，自己看)拜托了各位 谢谢等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！