CDH中的Hive文件系统权限

翻译： >Kafka是由LinkedIn设计的一个高吞吐量、分布式、基于发布订阅模式的消息系统，使用Scala编写，它以可水平扩展、可靠性、异步通信和高吞吐率等特性而被广泛使用。目前越来越多的开源分布式处理系统都支持与Kafka集成，其中Spark Streaming作为后端流引擎配合Kafka作为前端消息系统正成为当前流处理系统的主流架构之一。
然而，当下越来越多的安全漏洞、数据泄露等问题的爆发，安全正成为系统选型不得不考虑的问题，Kafka由于其安全机制的匮乏，也导致其在数据敏感行业的部署存在严重的安全隐患。本文将围绕Kafka，先介绍其整体架构和关键概念，再深入分析其架构之中存在的安全问题，最后分享下Transwarp在Kafka安全性上所做的工作及其使用方法。
Kafka架构与安全
首先，我们来了解下有关Kafka的几个基本概念：
Topic：Kafka把接收的消息按种类划分，每个种类都称之为Topic，由唯一的Topic Name标识。
Producer：向Topic发布消息的进程称为Producer。
Consumer：从Topic订阅消息的进程称为Consumer。
Broker：Kafka集群包含一个或多个服务器，这种服务器被称为Broker。
Kafka的整体架构如下图所示，典型的Kafka集群包含一组发布消息的Producer，一组管理Topic的Broker，和一组订阅消息的Consumer。Topic可以有多个分区，每个分区只存储于一个Broker。Producer可以按照一定的策略将消息划分给指定的分区，如简单的轮询各个分区或者按照特定字段的Hash值指定分区。Broker需要通过ZooKeeper记录集群的所有Broker、选举分区的Leader，记录Consumer的消费消息的偏移量，以及在Consumer Group发生变化时进行relalance Broker接收和发送消息是被动的：由Producer主动发送消息，Consumer主动拉取消息。
然而，分析Kafka框架，我们会发现以下严重的安全问题：
1网络中的任何一台主机，都可以通过启动Broker进程而加入Kafka集群，能够接收Producer的消息，能够篡改消息并发送给Consumer。
2网络中的任何一台主机，都可以启动恶意的Producer/Consumer连接到Broker，发送非法消息或拉取隐私消息数据。
3Broker不支持连接到启用Kerberos认证的ZooKeeper集群，没有对存放在ZooKeeper上的数据设置权限。任意用户都能够直接访问ZooKeeper集群，对这些数据进行修改或删除。
4Kafka中的Topic不支持设置访问控制列表，任意连接到Kafka集群的Consumer（或Producer）都能对任意Topic读取（或发送）消息。
随着Kafka应用场景越来越广泛，特别是一些数据隐私程度较高的领域（如道路交通的视频监控），上述安全问题的存在犹如一颗定时炸d，一旦内网被黑客入侵或者内部出现恶意用户，所有的隐私数据（如车辆出行记录）都能够轻易地被窃取，而无需攻破Broker所在的服务器。
Kafka安全设计
基于上述分析，Transwarp从以下两个方面增强Kafka的安全性：
身份认证（Authentication）：设计并实现了基于Kerberos和基于IP的两种身份认证机制。前者为强身份认证，相比于后者具有更好的安全性，后者适用于IP地址可信的网络环境，相比于前者部署更为简便。
权限控制（Authorization）：设计并实现了Topic级别的权限模型。Topic的权限分为READ（从Topic拉取数据）、WRITE（向Topic中生产数据）、CREATE（创建Topic）和DELETE（删除Topic）。
基于Kerberos的身份机制如下图所示：
Broker启动时，需要使用配置文件中的身份和密钥文件向KDC（Kerberos服务器）认证，认证通过则加入Kafka集群，否则报错退出。
Producer（或Consumer）启动后需要经过如下步骤与Broker建立安全的Socket连接：
1Producer向KDC认证身份，通过则得到TGT（票证请求票证），否则报错退出
2Producer使用TGT向KDC请求Kafka服务，KDC验证TGT并向Producer返回SessionKey（会话密钥）和ServiceTicket（服务票证）
3Producer使用SessionKey和ServiceTicket与Broker建立连接，Broker使用自身的密钥解密ServiceTicket，获得与Producer通信的SessionKey，然后使用SessionKey验证Producer的身份，通过则建立连接，否则拒绝连接。
ZooKeeper需要启用Kerberos认证模式，保证Broker或Consumer与其的连接是安全的。
Topic的访问控制列表（ACL）存储于ZooKeeper中，存储节点的路径为/acl/<topic>/<user>，节点数据为R(ead)、W(rite)、C(reate)、D(elete)权限的集合，如/acl/transaction/jack节点的数据为RW，则表示用户jack能够对transaction这个topic进行读和写。
另外，kafka为特权用户，只有kafka用户能够赋予/取消权限。因此，ACL相关的ZooKeeper节点权限为kafka具有所有权限，其他用户不具有任何权限。
构建安全的Kafka服务
首先，我们为Broker启用Kerberos认证模式，配置文件为/etc/kafka/conf/serverproperties，安全相关的参数如下所示：
其中，authentication参数表示认证模式，可选配置项为simple, kerberos和ipaddress，默认为simple。当认证模式为kerberos时，需要额外配置账户属性principal和对应的密钥文件路径keytab
认证模式为ipaddress时，Producer和Consumer创建时不需要做任何改变。而认证模式为kerberos时，需要预先创建好相应的principal和keytab，并使用API进行登录，样例代码如下所示：
public class SecureProducer extends Thread {
private final kafkajavaapiproducerProducer<Integer, String> producer;
private final String topic;
private final Properties props = new Properties();
public SecureProducer(String topic) {
AuthenticationManagersetAuthMethod(“kerberos”);
AuthenticationManagerlogin(“producer1″, “/etc/producer1keytab”);
propsput(“serializerclass”, “kafkaserializerStringEncoder”);
propsput(“metadatabrokerlist”,
“172161190:9092,172161192:9092,172161193:9092″);
// Use random partitioner Don’t need the key type Just set it to Integer
// The message is of type String
producer = new kafkajavaapiproducerProducer<Integer, String>(
new ProducerConfig(props));
thistopic = topic;

1 Hadoop HA架构详解

11 HDFS HA背景

HDFS集群中NameNode 存在单点故障（SPOF）。对于只有一个NameNode的集群，如果NameNode机器出现意外情况，将导致整个集群无法使用，直到NameNode 重新启动。

影响HDFS集群不可用主要包括以下两种情况：一是NameNode机器宕机，将导致集群不可用，重启NameNode之后才可使用；二是计划内的NameNode节点软件或硬件升级，导致集群在短时间内不可用。

为了解决上述问题，Hadoop给出了HDFS的高可用HA方案：HDFS通常由两个NameNode组成，一个处于active状态，另一个处于standby状态。Active NameNode对外提供服务，比如处理来自客户端的RPC请求，而Standby NameNode则不对外提供服务，仅同步Active NameNode的状态，以便能够在它失败时快速进行切换。

12 HDFS HA架构

一个典型的HA集群，NameNode会被配置在两台独立的机器上，在任何时间上，一个NameNode处于活动状态，而另一个NameNode处于备份状态，活动状态的NameNode会响应集群中所有的客户端，备份状态的NameNode只是作为一个副本，保证在必要的时候提供一个快速的转移。

为了让Standby Node与Active Node保持同步，这两个Node都与一组称为JNS的互相独立的进程保持通信(Journal Nodes)。当Active Node上更新了namespace，它将记录修改日志发送给JNS的多数派。Standby noes将会从JNS中读取这些edits，并持续关注它们对日志的变更。Standby Node将日志变更应用在自己的namespace中，当failover发生时，Standby将会在提升自己为Active之前，确保能够从JNS中读取所有的edits，即在failover发生之前Standy持有的namespace应该与Active保持完全同步。

为了支持快速failover，Standby node持有集群中blocks的最新位置是非常必要的。为了达到这一目的，DataNodes上需要同时配置这两个Namenode的地址，同时和它们都建立心跳链接，并把block位置发送给它们。

任何时刻，只有一个Active NameNode是非常重要的，否则将会导致集群 *** 作的混乱，那么两个NameNode将会分别有两种不同的数据状态，可能会导致数据丢失，或者状态异常，这种情况通常称为“split-brain”（脑裂，三节点通讯阻断，即集群中不同的Datanodes却看到了两个Active NameNodes）。对于JNS而言，任何时候只允许一个NameNode作为writer；在failover期间，原来的Standby Node将会接管Active的所有职能，并负责向JNS写入日志记录，这就阻止了其他NameNode基于处于Active状态的问题。

基于QJM的HDFS HA方案如上图所示，其处理流程为：集群启动后一个NameNode处于Active状态，并提供服务，处理客户端和DataNode的请求，并把editlog写到本地和share editlog（这里是QJM）中。另外一个NameNode处于Standby状态，它启动的时候加载fsimage，然后周期性的从share editlog中获取editlog，保持与Active节点的状态同步。为了实现Standby在Active挂掉后迅速提供服务，需要DataNode同时向两个NameNode汇报，使得Stadnby保存block to DataNode信息，因为NameNode启动中最费时的工作是处理所有DataNode的blockreport。为了实现热备，增加FailoverController和Zookeeper，FailoverController与Zookeeper通信，通过Zookeeper选举机制，FailoverController通过RPC让NameNode转换为Active或Standby。

13 HDFS HA配置要素

NameNode机器：两台配置对等的物理机器，它们分别运行Active和Standby Node。

JouralNode机器：运行JouralNodes的机器。JouralNode守护进程相当的轻量级，可以和Hadoop的其他进程部署在一起，比如NameNode、DataNode、ResourceManager等，至少需要3个且为奇数，如果你运行了N个JNS，那么它可以允许(N-1)/2个JNS进程失效并且不影响工作。

在HA集群中，Standby NameNode还会对namespace进行checkpoint *** 作（继承Backup Namenode的特性），因此不需要在HA集群中运行SecondaryNameNode、CheckpointNode或者BackupNode。

14 HDFS HA配置参数

需要在hdfsxml中配置如下参数：

dfsnameservices：HDFS NN的逻辑名称，例如myhdfs。

dfshanamenodesmyhdfs：给定服务逻辑名称myhdfs的节点列表，如nn1、nn2。

dfsnamenoderpc-addressmyhdfsnn1：myhdfs中nn1对外服务的RPC地址。

dfsnamenode>

dfsnamenodesharededitsdir：JournalNode的服务地址。

dfsjournalnodeeditsdir：JournalNode在本地磁盘存放数据的位置。

dfshaautomatic-failoverenabled：是否开启NameNode失败自动切换。

dfshafencingmethods ：配置隔离机制，通常为sshfence。

15 HDFS自动故障转移

HDFS的自动故障转移主要由Zookeeper和ZKFC两个组件组成。

Zookeeper集群作用主要有：一是故障监控。每个NameNode将会和Zookeeper建立一个持久session，如果NameNode失效，那么此session将会过期失效，此后Zookeeper将会通知另一个Namenode，然后触发Failover；二是NameNode选举。ZooKeeper提供了简单的机制来实现Acitve Node选举，如果当前Active失效，Standby将会获取一个特定的排他锁，那么获取锁的Node接下来将会成为Active。

ZKFC是一个Zookeeper的客户端，它主要用来监测和管理NameNodes的状态，每个NameNode机器上都会运行一个ZKFC程序，它的职责主要有：一是健康监控。ZKFC间歇性的ping NameNode，得到NameNode返回状态，如果NameNode失效或者不健康，那么ZKFS将会标记其为不健康；二是Zookeeper会话管理。当本地NaneNode运行良好时，ZKFC将会持有一个Zookeeper session，如果本地NameNode为Active，它同时也持有一个“排他锁”znode，如果session过期，那么次lock所对应的znode也将被删除；三是选举。当集群中其中一个NameNode宕机，Zookeeper会自动将另一个激活。

16 YARN HA架构

YARN的HA架构和HDFSHA类似，需要启动两个ResourceManager，这两个ResourceManager会向ZooKeeper集群注册，通过ZooKeeper管理它们的状态（Active或Standby）并进行自动故障转移。

2 高可用集群规划

21 集群规划

根据Hadoop的HA架构分析，规划整个集群由5台主机组成，具体情况如下表所示：

主机名

IP地址

安装的软件

JPS

hadoop-master1

172162081

Jdk/hadoop

Namenode/zkfc/resourcemanager/

JobHistoryServer

hadoop-master2

172162082

Jdk/hadoop

Namenode/zkfc/resourcemanager/

WebProxyServer

hadoop-slave1

172162083

Jkd/hadoop/zookeepe

Datanode/journalnode/nodemanager/

quorumPeerMain

hadoop-slave2

172162084

Jkd/hadoop/zookeeper

Datanode/journalnode/nodemanager/

quorumPeerMain

hadoop-slave3

172162085

Jkd/hadoop/zookeeper

Datanode/journalnode/nodemanager/

quorumPeerMain

需要说明以下几点：

HDFS HA通常由两个NameNode组成，一个处于Active状态，另一个处于Standby状态。Active NameNode对外提供服务，而Standby NameNode则不对外提供服务，仅同步Active NameNode的状态，以便能够在它失败时快速进行切换。

Hadoop 20官方提供了两种HDFS HA的解决方案，一种是NFS，另一种是QJM。这里我们使用简单的QJM。在该方案中，主备NameNode之间通过一组JournalNode同步元数据信息，一条数据只要成功写入多数JournalNode即认为写入成功。通常配置奇数个JournalNode，这里还配置了一个Zookeeper集群，用于ZKFC故障转移，当Active NameNode挂掉了，会自动切换Standby NameNode为Active状态。

YARN的ResourceManager也存在单点故障问题，这个问题在hadoop-241得到了解决：有两个ResourceManager，一个是Active，一个是Standby，状态由zookeeper进行协调。

YARN框架下的MapReduce可以开启JobHistoryServer来记录历史任务信息，否则只能查看当前正在执行的任务信息。

Zookeeper的作用是负责HDFS中NameNode主备节点的选举，和YARN框架下ResourceManaer主备节点的选举。

22 软件版本

*** 作系统：CentOS Linux release 701406

JDK：Java(TM)SE Runtime Environment (build 170_79-b15)

Hadoop：Hadoop 260-cdh571

ZooKeeper：zookeeper-345-cdh571

3 Linux环境准备

集群各节点进行如下修改配置：

31 创建用户并添加权限

// 切换root用户

$ su root

// 创建hadoop用户组

# groupadd hadoop

// 在hadoop用户组中创建hadoop用户

# useradd -g hadoop hadoop

// 修改用户hadoop密码

# passwd hadoop

// 修改sudoers配置文件给hadoop用户添加sudo权限

# vim /etc/sudoers

hadoop    ALL=(ALL)       ALL

// 测试是否添加权限成功

# exit

$ sudo ls /root

32 修改IP地址和主机名

// 切换root用户

$ su root

// 修改本机IP地址

# vim /etc/sysconfig/network-scripts/ifcfg-eth0

// 重启网络服务

# service network restart

// 修改主机名

# hostnamectl set-hostname 主机名

// 查看主机名

# hostnamectl status

33 设置IP地址与主机名映射

// 切换root用户

$ su root

// 编辑hosts文件

# vim /etc/hosts

172162081    hadoop-master1

172162082    hadoop-master2

172162083    hadoop-slave1

172162084    hadoop-slave2

172162085    hadoop-slave3

34 关闭防火墙和Selinux

// 切换root用户

$ su root

// 停止firewall防火墙

# systemctl stop firewalldservice

// 禁止firewall开机启动

# systemctl disable firewalldservice

// 开机关闭Selinux

# vim /etc/selinux/config

SELINUX=disabled

// 重启机器后root用户查看Selinux状态

# getenforce

35 配置SSH免密码登录

// 在hadoop-master1节点生成SSH密钥对

$ ssh-keygen -t rsa

// 将公钥复制到集群所有节点机器上

$ ssh-copy-id hadoop-master1

$ ssh-copy-id hadoop-master2

$ ssh-copy-id hadoop-slave1

$ ssh-copy-id hadoop-slave2

$ ssh-copy-id hadoop-slave3

// 通过ssh登录各节点测试是否免密码登录成功

$ ssh hadoop-master2

备注：在其余节点上执行同样的 *** 作，确保集群中任意节点都可以ssh免密码登录到其它各节点。

36 安装JDK

// 卸载系统自带的openjdk

$ suroot

# rpm-qa | grep java

# rpm-e --nodeps java-170-openjdk-17075-2542el7_0x86_64

# rpm-e --nodeps java-170-openjdk-headless-17075-2542el7_0x86_64

# rpm-e --nodeps tzdata-java-2015a-1el7_0noarch

# exit

// 解压jdk安装包

$ tar-xvf jdk-7u79-linux-x64targz

// 删除安装包

$ rmjdk-7u79-linux-x64targz

// 修改用户环境变量

$ cd ~

$ vimbash_profile

exportJAVA_HOME=/home/hadoop/app/jdk170_79

exportPATH=$PATH:$JAVA_HOME/bin

// 使修改的环境变量生效

$ sourcebash_profile

// 测试jdk是否安装成功

$ java-version

4 集群时间同步

如果集群节点时间不同步，可能会出现节点宕机或引发其它异常问题，所以在生产环境中一般通过配置NTP服务器实现集群时间同步。本集群在hadoop-master1节点设置ntp服务器，具体方法如下：

// 切换root用户

$ su root

// 查看是否安装ntp

# rpm -qa | grep ntp

// 安装ntp

# yum install -y ntp

// 配置时间服务器

# vim /etc/ntpconf

# 禁止所有机器连接ntp服务器

restrict default ignore

# 允许局域网内的所有机器连接ntp服务器

restrict 17216200 mask 2552552550 nomodify notrap

# 使用本机作为时间服务器

server 12712710

// 启动ntp服务器

# service ntpd start

// 设置ntp服务器开机自动启动

# chkconfig ntpd on

集群其它节点通过执行crontab定时任务，每天在指定时间向ntp服务器进行时间同步，方法如下：

// 切换root用户

$ su root

// 执行定时任务，每天00:00向服务器同步时间，并写入日志

# crontab -e

0       0                           /usr/sbin/ntpdate hadoop-master1>> /home/hadoop/ntpdlog

// 查看任务

# crontab -l

5 Zookeeper集群安装

Zookeeper是一个开源分布式协调服务，其独特的Leader-Follower集群结构，很好的解决了分布式单点问题。目前主要用于诸如：统一命名服务、配置管理、锁服务、集群管理等场景。大数据应用中主要使用Zookeeper的集群管理功能。

本集群使用zookeeper-345-cdh571版本。首先在hadoop-slave1节点安装Zookeeper，方法如下：

// 新建目录

$ mkdir app/cdh

// 解压zookeeper安装包

$ tar -xvf zookeeper-345-cdh571targz -C app/cdh/

// 删除安装包

$ rm -rf zookeeper-345-cdh571targz

// 配置用户环境变量

$ vim bash_profile

export ZOOKEEPER_HOME=/home/hadoop/app/cdh/zookeeper-345-cdh571

export PATH=$PATH:$ZOOKEEPER_HOME/bin

// 使修改的环境变量生效

$ sourcebash_profile

// 修改zookeeper的配置文件

$ cd app/cdh/zookeeper-345-cdh571/conf/

$ cp zoo_samplecfg zoocfg

$ vim zoocfg

# 客户端心跳时间(毫秒)

tickTime=2000

# 允许心跳间隔的最大时间

initLimit=10

# 同步时限

syncLimit=5

# 数据存储目录

dataDir=/home/hadoop/app/cdh/zookeeper-345-cdh571/data

# 数据日志存储目录

dataLogDir=/home/hadoop/app/cdh/zookeeper-345-cdh571/data/log

# 端口号

clientPort=2181

# 集群节点和服务端口配置

server1=hadoop-slave1:2888:3888

server2=hadoop-slave2:2888:3888

server3=hadoop-slave3:2888:3888

# 以下为优化配置

# 服务器最大连接数，默认为10，改为0表示无限制

maxClientCnxns=0

# 快照数

autopurgesnapRetainCount=3

# 快照清理时间，默认为0

autopurgepurgeInterval=1

// 创建zookeeper的数据存储目录和日志存储目录

$ cd

$ mkdir -p data/log

// 在data目录中创建一个文件myid，输入内容为1

$ echo "1" >> data/myid

// 修改zookeeper的日志输出路径(注意CDH版与原生版配置文件不同)

$ vim libexec/zkEnvsh

if [ "x${ZOO_LOG_DIR}" = "x" ]

then

ZOO_LOG_DIR="$ZOOKEEPER_HOME/logs"

fi

if [ "x${ZOO_LOG4J_PROP}" = "x" ]

then

ZOO_LOG4J_PROP="INFO,ROLLINGFILE"

fi

// 修改zookeeper的日志配置文件

$ vim conf/log4jproperties

zookeeperrootlogger=INFO,ROLLINGFILE

// 创建日志目录

$ mkdir logs

将hadoop-slave1节点上的Zookeeper目录同步到hadoop-slave2和hadoop-slave3节点，并修改Zookeeper的数据文件。此外，不要忘记设置用户环境变量。

// 在hadoop-slave1中将zookeeper目录复制到其它节点

$ cd ~

$ scp -r app/cdh/zookeeper-345-cdh571hadoop-slave2:/home/hadoop/app/cdh

$ scp -r app/cdh/zookeeper-345-cdh571 hadoop-slave3:/home/hadoop/app/cdh

//在hadoop-slave2中修改data目录中的myid文件

$ echo "2" >app/cdh/zookeeper-345-cdh571/data/myid

//在hadoop-slave3中修改data目录中的myid文件

$ echo "3" >app/cdh/zookeeper-345-cdh571/data/myid

最后，在安装了Zookeeper的各节点上启动Zookeeper，并查看节点状态，方法如下：

// 启动

$ zkServersh start

// 查看状态

$ zkServersh status

// 关闭

1、下载hive(>

云服务器和传统服务器的对比

相较于传统服务器的物理性，需要专门的地方建设技机房。并且在前期建设成本高，不灵活、容易造成浪费和不够用的情况。云服务器虚拟化的性质，只需要根据自己的需求按需租用前期投入小；软件、项目实施周期短；d性大，灵活；云服务器厂家做到一定的基础网络安全和运维。这样诸多的优点，自然有越来越多企业用上云服务器。

云服务器种类繁多，有专用宿主机、普通云服务器、轻量应用服务器、黑石物理服务器、GPU云服务器，企业可以针对性的做出选择，不同种类的云服务器适用于不同的使用场景，企业如何选择适合自己的云服务器是重中之重。下面，就拿专用宿主机为例来给朋友们介绍一下关于云服务器的优势吧。

云服务器之专用宿主机

很多上云且对安全有一定要求的企业对专用宿主机一定都不陌生，专用宿主机是资源独享、物理隔离的云端计算服务，主要用来满足企业资源独享、安全、合规的需求。使用专用宿主机可以灵活创建、管理多个自定义规格的云服务器实例，自主规划物理资源的使用。企业在什么情况下适合使用专用宿主机，以及专用宿主机有哪些特点，一起来看一下。

专用宿主机的特点

1 专用宿主机的核心在于安全，是企业资源独享需求的不二选择。专用宿主机提供物理机级别的资源独享。

2 虽然使用的是云服务器，但用户可以自主规划宿主机内资源的使用，避免其他租户的资源竞争。所以也一定程度上满足了安全合规的要求，CPU、内存、磁盘、网络资源均单租户专用。物理机级别资源隔离，提供敏感业务数据保护、磁盘消磁能力，满足金融行业强监管需求。

专用宿主机

3 除了安全性之外，专用宿主机CDH在性能方面也完全不弱于经典的CVM。

(1) 首先灵活性方面，用户可以在指定的专用宿主机上分配云服务器并自主规划宿主机资源的使用。专用宿主机的实例规格支持自定义，可以灵活配置，打破子机规格的限制，保障业务性能的同时充分利用物理服务器资源。

(2) 同时也具有CVM的特性，独享子机即专用宿主机上创建的云服务器 CVM，提供镜像、安全组、配置调整、SSH 密钥等支持，各功能特性的使用方式也保持跟普通 CVM 一致。

4最后一大特性就是虽然安全性更高，性能不弱，但在价格上仍然具有优势。一般采用的是按需购买的方式，分钟级交付，具备统一标准的运维管理服务，保障企业用户的资源稳定运行，客户无需关注底层运维，大大节省人力、节约运维成本，让企业可以专注于核心业务。

云主机

专用宿主服务器适用场景

如此优秀的专用宿主服务器对于企业来说，更适合于两种场景，一个是金融业务场景，一个是高性能业务场景。

金融业务

首先金融业务往往有更严格的安全合规性要求，使用专用宿主服务器可以在资源共享的同时保证与其他用户的子机物理隔离，满足敏感业务数据保护、磁盘消磁需求。

高性能的业务场景

高性能的业务场景下，使用专用宿主机能够保障物理服务器资源的独享，用户自行规划专用宿主机上业务的部署，在充分利用资源的同时避免资源抢占。

希望本篇回答可以帮助到你

望采纳~

---