erp系统部署方案有哪些

erp系统部署方案有哪些？在ERP领域，之前并没有普遍适用的系统实施策略，未来可能也不会有。但大体而言，有两种部署策略是普遍应用的，即本地化部署和SaaS化部署。那么，这两种方案各有什么优缺点呢？

erp系统部署方案：

一、本地化部署

所谓本地化部署就是，系统的服务器部署在企业内部，用户通过访问公司内的服务器即可操作软件，数据存储在公司的服务器上。如果您需要外网访问，则需要通过VPN来接入。

优点：

本地部署是基于企业自身的服务器部署，数据无需上传至第三方服务器或云端，本地经营数据的安全性更有保障；

本地化部署可本地开发，满足灵活扩展各类应用，在应用ERP时存在一些个性化的需求，可自行开发更新；

便于系统对接，可以针对需求对接OA、MES、CRM、WMS等自有系统，无需再经过软件厂商介入造成数据泄露；

服务器资源可控，按照需求灵活调配，扩展性高。

缺点：

投入更多的成本与精力，其中包含服务器硬件成本、维护和管理成本；

系统上线周期更长，在部署实施阶段会花费大量时间与人力；

系统访问便携性不强，外网环境下需要连接vpn。

二、SaaS化部署

SaaS化部署是软件应用服务商，通过互联网向企业用户提供软件应用的模式，企业无需在本地配置服务器和安装系统软件，只需通过互联网即可使用ERP系统。同时可以根据自己需求，向ERP厂商提出对应的诉求，让其更新。

优点：

SaaS化部署软件不需要考虑复杂的服务器采购、机房布局、网络配置、后期运维等专业的IT问题；

ERP厂商将进行持续的产品更新迭代，以确保用户可以接收应用程序的最新版本，且不需要支付额外的费用；

用户可通过外网访问，实现随时可进行访问系统，处理业务问题；

成本较低，企业无需进行硬件及运维成本投入，只需要对软件付更少的费用使用即可。

缺点：

业务经营数据存储在三方，并非自己手中，会有一定的数据泄露等安全问题；

软件迭代需依赖ERP厂商，不能做到一些非常个性化的需求满足；

系统二次开发麻烦，不能很好的满足企业间的系统对接问题。

不同的ERP部署方式发挥着不同的优势，一般来讲，比较大的国企/上市公司注重数据安全与效率，采用本地化部署的ERP，有自己单位的IT部门进行维护使用而一些中小微企业，对信息化要求不那么高，同时没有专业IT部门，更适合采用SaaS化部署的ERP系统。

说说我以前最常用的三种批量部署方案(有疑问接受私信):

第一:服务器一般都会用两块磁盘做RAID1作为系统盘，手动安装完第一台操作系统，RAID1的功能是两块盘中具有相等的数据，所以两块盘都存在了刚刚安装好的linux系统，拔出一块系统盘(服务器认为你这块盘坏了)，再插入一块新盘到刚刚拔出磁盘的位置，此时服务器会再次向新磁盘自动同步数据，保持1:1备份。接下来刚刚拔出的那块系统盘派上用场，把刚刚扒出来的那块有系统的盘插到另外一台无系统的服务器上，自动完成与另外一块盘的同步，以此类推，1生2，2生4，4生8，8生16，16生32

第二种:刻录无人值守光盘

第三种:PXE批量部署

PXE实例:

我3年前做过一套PXE部署系统(以下是当时用于机房部署系统的截图界面)。可以部署windows+linux的各个版本，部署服务器采用的windows系统(因为windows能通过easybcd制作syslinux引导)，syslinux就可以成功引导起win和linux，引导成功后，调用kickstart制作的linux无人应答文件，wds &AKT制作的windows无人应答文件，完成系统安装。你的需求只需要安装统一的linux版本，所以相对来说比较容易，花两天学习下kickstart基本就能在虚拟机上实践成功，但是如果要应用到物理服务器，还需要考虑驱动，raid，格式化等问题

解决办法当然是PXE+Kickstart了，学会一次就能一直用很方便。

你需要准备：

1、交换机，用于连接Server和客户机(必须临时关闭DHCP)

2、部署用server主机（由此台主机接管DHCP服务）

3、其他一堆客户机（需要调节至PXE引导模式）

然后按照教程

https://andyx.net/pxe_kickstart_automatic_deployment_of_linux_system/对Server

主机进行部署PXE+Kickstart，完成之后客户端开机即可自动安装。

没有部署同时过100多台，但是曾经部署26台ECS集群，支撑1500左右tps。部署的方案是：阿里云ECS+镜像+弹性伸缩+负载均衡。开发测试环境用的是Vagrant直接控制多台虚拟机，曾经也使用过VMware ESXi和VMware VCenter管理虚拟机集群

腾讯有个蓝鲸平台，只需要录入你的服务器ip就可以批量操作。

还有一个ansible的来源运维工具。

还可以通过pexpect脚本，自己用python结合ssh搭建一个运维平台。

如果是批量买机器的话，各个云厂商都提供有接口，写个简单都shell就可以了。

阿里云前天刚发布的，叫什么servicefee,忘了，可视化部署，一键拉起，可设置拉起顺序，定时弹性容灾，服务之间的调用可视化，其他数据也是可监控

会 python 和 shell 可以搞搞 fabric ，我在用，还不错！

看你部署应用还是系统，平台是什么。

系统简单，做个模板机，复制就行了。

应用也不麻烦，跟上边的一样做个镜像就行，或者用批量管理工具ansible salt 这类的工具。云服务器的话，镜像市场也有公用的。

ansible，puppet和chef是常用的自动化运维工具。你说的需求用这三个都能做

1.部署操作系统，制作系统模板，批量创建或调用api接口即可

2.部署应用软件，可使用自动化工具如ansible或者编写脚本来批量部署

linux有类似ghost那样的克隆工具，推荐clonezilla。ghost for Linux也可以。

另外，Linux下的dd命令可以完成一个源驱动器对目标驱动器的镜像操作。

WSUS服务器配置方案包括单服务器、层次或链型服务器群、复制服务器、无链接服务器、多服务器。

单服务器：只有一台WSUS服务器，微软更新站点作为更新源

层次或链型服务器群：当站点中有许多客户机，可以部署多台WSUS服务器来提高性能。WSUS服务器通常从其它的WSUS服务器获取更新。提供更新的服务器叫上游服务器，从上游服务器获得更新的服务器叫下游服务器。在整个层次结构中，配置必须保持一致，即每台服务器必须使用相同的更新文件存储位置，内容过滤（产品类别的订阅，更新分类和语言）必须统一。最上游的服务器批准来自微软更新站点的更新，下游服务器只能从上游服务器下载那些批准的更新。下游服务器对于那些上游服务器未批准的理新将一无所知。上游服务器提供一个全局批准清单，下游服务器维护相同的更新清单或是清单的子集。同时，WSUS服务器同时也是客户机，它也必须得到更新。应该WSUS从最上游的服务器获取更新。最下游服务器必须更新自身，推荐方法是单独定位服务器（即把服务器放在它自己的目标湘计算机组），并在应用更新之后批准WSUS相关更新。

复制服务器：是上游服务器的镜像。一台复制服务器将把上游伙伴服务器的全部配置都复制过来，包括更新、批准、目标和组。服务器唯一可管理的是计算机组成员关系。它支持集中的更新批准策略并可以将更新发布到多台服务器。要将一台现有的WSUS服务器配置为复制服务器，必须重新安装WSUS。

无链接服务器：使用WSUTIL命令从一台更新服务器导出更新，再在另一台服务器上导入。

多服器：是单服务器拓扑的简单复制。

单服务器是最简单的拓扑，也是广泛采用的解决方案。层次或链型服务器群适合那些资源分布在多个地理位置上，采用集中管理策略的企业；复制服务器提高了较大的灵活性，可以由复制服务器的管理员决定哪些客户机将接收哪些补丁；无链接服务器可以通过可移动介质而不是网络从其它的WSUS服务器上获取更新；多服务器拓扑就是单服务器的简单复制，用于支持更大的网络；

---