centos搭建pxe，centos7
这篇文章给大家聊聊关于centos搭建pxe，以及centos7对应的知识点，希望对各位有所帮助，不要忘了收藏本站哦。
Proxmox 服务器搭建全过程
一、服务器配置过程说明
首先，在服务器上安装window server，然后配置为RAID 5存储阵列。接着，创建Proxmox集群与KVM，为节点安装centos系统，下载Teamviewer。最后，讲解节点备份与恢复的方法。
二、RAID配置
RAID配置包括理解RAID概念，选择RAID 5模式以提高安全性与容错性。通过操作向导，清除默认RAID 0配置，选择RAID 5模式，完成RAID配置。
三、创建Proxmox集群
通过无界面操作，选择UEFI或PXE boot方式，完成安装集群的步骤。使用命令行操作搭建集群，解决安装过程中的问题，如编辑器与hosts文件参数修改，确保集群正常运行。
四、创建KVM虚拟节点
在数据中心创建虚拟节点，选择Linux操作系统，配置虚拟机参数如内存、硬盘、网络等，完成KVM虚拟节点的创建。
五、节点上CentOS系统安装
注意安装界面的操作，选择不使用图形界面，安装系统后，通过命令行方式配置分区、格式化磁盘、设置用户信息，完成系统安装。
六、配置IP与下载Teamviewer
设置节点网络为NAT模式，手动配置IP地址、子网掩码、网关及DNS。下载并安装Teamviewer，设置开机自启，方便远程控制。
七、Proxmox节点恢复与备份
设置节点备份，选择存储位置与虚拟机，自动执行备份计划或立即备份。提供方法挂载磁盘，从备份文件中恢复数据，确保数据安全。
问题解决：对于节点无法关闭或开启的情况，可参考官网信息或使用命令行操作解除锁状态，解决问题。
如何最快搭建LINUX服务器集群
1.2.并行技术
这是一个非常简单的建造四节点的小集群系统的例子，它是构建在Linux操作系统上，通过MPICH软件包实现的，希望这个小例子能让大家对集群系统的构建有一个最基本的了解。
2.使用MPICH构建一个四节点的集群系统
这是一个非常简单的建造四节点的小集群系统的例子，它是构建在Linux操作系统上，通过MPICH软件包实现的，希望这个小例子能让大家对集群系统的构建有一个最基本的了解。
2.1所需设备
1).4台采用Pentium II处理器的PC机，每台配
置64M内存，2GB以上的硬盘，和EIDE接口的光盘驱动器。
2).5块100M快速以太网卡，如SMC 9332 EtherPower 10/100(其中四块卡用于连接集群中的结点，另外一块用于将集群中的其中的一个节点与其它网络连接。)
3).5根足够连接集群系统中每个节点的，使用5类非屏蔽双绞线制作的RJ45缆线
4).1个快速以太网(100BASE-Tx)的集线器或交换机
5).1张Linux安装盘
2.2构建说明
对计算机硬件不熟的人，实施以下这些构建步骤会感到吃力。如果是这样，请找一些有经验的专业人士寻求帮助。
1.准备好要使用的采用Pentium II处理器的PC机。确信所有的PC机都还没有接上电源，打开PC机的机箱，在准备与网络上的其它设备连接的PC机上安装上两块快速以太网卡，在其它的 PC机上安装上一块快速以太网卡。当然别忘了要加上附加的内存。确定完成后盖上机箱，接上电源。
2.使用4根RJ45线缆将四台PC机连到快速以太网的集线器或交换机上。使用剩下的1根RJ45线将额外的以太网卡(用于与其它网络相连的那块，这样机构就可以用上集群)连接到机构的局域网上(假定你的机构局域网也是快速以太网)，然后打开电源。
3.使用LINUX安装盘在每一台PC机上安装。请确信在LINUX系统中安装了C编译器和C的LIB库。当你配置TCP/IP时，建议你为四台PC分别指定为192.168.1.1、192.168.1.2、192.168.1.3、192.168.1.4。第一台PC为你的服务器节点(拥有两块网卡的那台)。在这个服务器节点上的那块与机构局域网相连的网卡，你应该为其指定一个与机构局域网吻合的IP地址。
4.当所有PC都装好Linux系统后，编辑每台机器的/etc/hosts文件，让其包含以下几行：
192.168.1.1 node1 server
192.168.1.2 node2
192.168.1.3 node3
192.168.1.4 node4
编辑每台机器的/etc/hosts.equiv文件，使其包含以下几行：
node1
node2
node3
node4
$p#
以下的这些配置是为了让其能使用MPICH’s p4策略去执行分布式的并行处理应用。
1.在服务器节点
，建一个/mirror目录，并将其配置成为NFS服务器，并在/etc/exports文件中增加一行：
/mirror node1(rw) node2(rw) node3(rw) node4(rw)
2.在其他节点上，也建一个/mirror目录，关在/etc/fstab文件中增加一行：
server:/mirror/mirror nfs rw,bg,soft 0 0
3./mirror这个目录从服务器上输出，装载在各个客户端，以便在各个节点间进行软件任务的分发。
4.在服务器节点上，安装MPICH。MPICH的文档可在
5.任何一个集群用户(你必须在每一个节点新建一个相同的用户)，必须在/mirror目录下建一个属于它的子目录，如/mirror/username，用来存放MPI程序和共享数据文件。这种情况，用户仅仅需要在服务器节点上编译MPI程序，然后将编译后的程序拷贝到在/mirror目录下属于它的的子目录中，然后从他在/mirror目录下属于它的的子目录下使用p4 MPI策略运行MPI程序。
2.3 MPICH安装指南
1.如果你有gunzip，就d下载mpich.tar.gz，要不然就下载mpich.tar.Z。你可以到下载，也可以使用匿名FTP到ftp.mcs.anl.gov的pub/mpi目录拿。(如果你觉得这个东西太大，你可以到pub/mpi/mpisplit中取分隔成块的几个小包，然后用cat命令将它们合并)
2.解压：gunzip;c mpich.tar.gz tar xovf-(或zcat mpich.tar.Ztar xovf-)
3.进入mpich目录
4.执行：./configure为MPICH选择一套适合你的实际软硬件环境的参数组，如果你对这些默认选择的参数不满意，可以自己进行配置(具体参见MPICH的配置文档)。最好选择一个指定的目录来安装和配置MPICH，例如：
./configure-prefix=/usr/local/mpich-1.2.0
5.执行：make>&make.log这会花一段较长的时间，不同的硬件环境花的时间也就不同，可能从10分钟到1个小时，甚至更多。
6.(可选)在工作站网络，或是一台单独的工作站，编辑mpich/util/machines/machines.xxx(xxx是MPICH对你机器体系结构取的名称，你能很容易的认出来)以反映你工作站的当地主机名。你完全可以跳过这一步。在集群中，这一步不需要。
7.(可选)编译、运行一个简单的测试程序：
cd examples/basic
make cpi
ln;s../../bin/mpirun mpirun
./mpirun;np 4 cpi
此时，你就在你的系统上运行了一个MPI程序。
8.(可选)构建MPICH其余的环境，为ch_p4策略使
用安全的服务会使得任何启动速度加快，你可以执行以下命令构建：
make serv_p4
(serv_p4是一个较新的P4安全服务的版本，它包含在MPICH 1.2.0版中)，nupshot程序是upshot程序的一个更快版本，但他需要tk 3.6版的源代码。如果你有这个包，你就用以下命令可以构建它：
make nupshot
9.(可选)如果你想将MPICH安装到一个公用的地方让其它人使用它，你可以执行：
make install或 bin/mpiinstall
你可以使用-prefix选项指定MPICH安装目录。安装后将生成include、lib、bin、sbin、www和man目录以及一个小小的示例目录，
到此你可以通告所有的用户如何编译、执行一个MPI程序。
OpenStack部署都有哪些方式
对于每一个刚接触到OpenStack的新人而言，安装无疑是最困难的，同时这也客观上提高了大家学习OpenStack云计算的技术门槛。想一想，自己3年前网上偶然接触到OpenStack时，一头茫然，手动搭建一个多节点环境时居然用了3个星期。
时至今日，真是感触颇多，从某种角度而言，也很庆幸当时自己并未因困难而放弃OpenStack，否则，应该是去做其他领域了吧！
言归正传，咱们就来数落数落部署OpenStack都有哪些方式吧。这里，我们根据使用者群体的不同类型来进行分类和归纳：
个人使用方面
DevStack
无疑，在可预见的未来时间内，DevStack仍将是众多开发者们的首选安装方式或工具。该方式主要是通过配置参数，执行shell脚本来安装一个OpenStack的开发环境。
Github:
Wiki:
Rdo
Rdo是由Red Hat开源的一款部署OpenStack的工具，同DevStack一样，支持单节点和多节点部署。但Rdo只支持CentOS系列的操作系统。需要注意的是，该项目并不属于OpenStack官方社区项目。
Docs：
手动部署
手动部署all-in-one、multi-node、multi-HA-node环境。
其他
企业、团体方面
Puppet
Puppet由Ruby语言编写。应当说，Puppet是进入OpenStack自动化部署中的早期一批项目，历史还算悠久。目前，它的活跃开发群体们是Red hat、 Mirantis、UnitedStack等。
Red
hat自从收购Ansible之后，如今仍然保持强势劲头在Puppet
OpenStack项目中的Commit数量和质量，其技术实力不容小觑；Mirantis出品的Fuel部署工具中，大量的模块代码便使用的是
Puppet。就国内而言，UnitedStack是Puppet社区贡献和使用的最大用户。
Github：
Governance：
Wiki：
Ansible
Ansible
是新近出现的自动化运维工具，已被Red
Hat收购。基于Python开发，集合了众多运维工具（puppet、cfengine、chef、saltstack等）的优点，实现了批量系统配
置、批量程序部署、批量运行命令等功能，它一方面总结了Puppet的设计上的得失，另一方面也改进了很多设计。比如是基于SSH方式工作，故而不需要在
被控端安装客户端。使得在和OpenStack结合上没有历史包袱，更加能够轻装上阵，未来发展潜力不容小觑号称是“你一直寻找的下一代Iaas”的
Zstack，使用到的部署工具也是基于Ansible。
Openstack-ansible项目，最早是由老牌Rackspace公司在Launchpad官网上注册。
在最新的Ansible OpenStack项目社区Commit贡献中，Rackspace也可谓是遥遥领先，而紧随其后的是Red Hat、国内九州云等公司。
Github：
SaltStack
SaltStack
也是一款开源的自动化部署工具，基于Python开发，实现了批量系统配置、批量程序部署、批量运行命令等功能，和Ansible也是挺相近的。不同之一
是，由于SaltStack的master和minion认证机制和工作方式，需要在被控端安装minion客户端，在加之其他原因，自然和
Ansible相比，其优缺点便很明显了。
需要注意的是，使用Saltstack部署OpenStack，并不属于OpenStack社区项目。目前，主要还是处于用户自研自用的阶段。据笔者所知，目前国内的携程应该是使用Saltstack部署OpenStack规模最大的用户。
Saltstack部署OpenStack示例：
Saltstack部署OpenStack模块：
TripleO
Tripleo
项目最早由HP于2013.4在launchpad上注册BP。用于完成OpenStack的安装与部署。TripleO全称“OpenStack On
OpenStack”，意思即为“云上云”，可以简单理解为利用OpenStack来部署OpenStack，即首先基于V2P(和P2V相反，也就是指
把虚拟机的镜像迁移到物理机上)的理念事先准备好一些OpenStack节点（计算、存储、控制节点）的镜像，然后利用已有openstack环境的裸机
服务Ironic项目去部署裸机，软件安装部分的diskimage-builder，最后通过Heat项目和镜像内的DevOps工具(Puppet
Or Chef)再在裸机上配置运行openstack。
和其他部署工具不同的是，TripleO利用OpenStack本来的基础设施来部署OpenStack，基于Nova、 Neutron、Ironic和Heat，来自动化部署和伸缩OpenStack集群。
应
当确切的说，TripleO项目属于当前OpenStack社区主推的“Big Tent”开发模式下的big tent
project（OpenStack下的项目分为三种，core project: nova/neutron等核心项目，big tent
project:非核心项目，但也被OpenStack基金会接受；第三种就是其它项目，只是放在OpenStack下，但是社区还没有接受）。
在该项目的社区Commit贡献上，Red hat可谓是遥遥领先，而紧随其后的是IBM等公司。
Wiki：
Kolla
在
国内一些互联网资料上，常看到关于kolla是TripleO项目的一部分这样的描述，其实是不准确的。真实的是，Kolla项目起源于Tripleo项
目，时至今日，与它没有任何关系（虽然它们的目标都是做自动化部署，但走的道路却不同）。比之于Tripleo和其他部署工具，Kolla走的是
docker容器部署路线。
kolla项目起源于TripleO项目，聚焦于使用docker容器部署OpenStack服务。该项目由
Cisco于2014年9月提出，是OpenStack的孵化项目。当前Kolla项目在Kollaglue
repo提供了以下服务的docker镜像。# docker search kollaglue
Kolla的优势和使用场景，体现在如下几个方面：
原子性的升级或者回退OpenStack部署；
基于组件升级OpenStack；
基于组件回退OpenStack；
这里，我们予以拆分来理解：
Kolla
的最终目标是为OpenStack的每一个服务都创建一个对应的Docker Image，通过Docker
Image将升级的粒度减小到Service级别，从而使升级时，对OpenStack影响能达到最小，并且一旦升级失败，也很容易回滚。升级只需要三
步：Pull新版本的容器镜像，停止老版本的容器服务，然后启动新版本容器。回滚也不需要重新安装包了，直接启动老版本容器服务就行，非常方便。
Kolla是通过Docker Compose来部署OpenStack集群的，现在主要是针对裸机部署的，所以在部署Docker Container时，默认的网络配置都是Host模式。
首
先，只需要通过一个命令就可以把管理节点部署完成，这个命令是调用Docker
Compose来部署OpenStack的所有服务，然后我们可以在每一个计算节点上通过Docker
Compose安装计算节点需要的服务，就能部署一个OpenStack集群。因为Kolla的Docker
Image粒度很小，它针对每个OpenStack服务都有特定的Image，所以我们也可以通过Docker
Run来操作某个具体的OpenStack服务。
目前，我所在的公司九州云的一位同事近日获得提名成为Kolla项目Core。为OpenStack社区中增添了一份来自于中国的力量。
Fuel
Fuel
是针对OpenStack生产环境目标
（非开源）设计的一个端到端”一键部署“的工具，大量采用了Python、Ruby和JavaScript等语言。其功能含盖自动的PXE方式的操作系统
安装，DHCP服务，Orchestration服务和puppet配置管理相关服务等，此外还有OpenStack关键业务健康检查和log
实时查看等非常好用的服务。
Fuel，这款让很多人即爱且痛的工具，在国内外都很盛名。爱的原因是，它确实很棒；痛的原因是，要想彻底掌握
它，可不是一件容易事（各个模块集成度高、使用技术复杂）。既然提到Fuel，自然不能不提它的父母——Mirantis。Mirantis是一家技术实
力非常雄厚的OpenStack服务集成商，他是社区贡献排名前5名中唯一一个靠OpenStack软件和服务盈利的公司。同时，Fuel的版本节奏也很
快，平均每半年就能提供一个相对稳定的社区版。
从和笔者接触到的一些情况来看，国内研究、使用Fuel的个人、群体还是为数不少的。不少国内OpenStack初创公司的安装包就是基于Fuel去修改的。
