Citrix 的优缺点有哪些

VMware view是属于VDI虚拟化部署的一个桌面虚拟化软件，而支持这个虚拟化部署环境的云终端机是服务器端与员工终端通信办公连接的桥梁。即利用VMware view通过服务器虚拟化出多个用户桌面，再通过员工使用的云终端机一个个显示出来，就像一台台电脑一样，可以完成电脑各种 *** 作任务。
VMware vshper(esx/esxi) 服务器虚拟化 VMware Horizon view 5 桌面虚拟化
citrix xenserver 是免费的,VDI模式需要citrix xendesktop，但license费用高。
相比微软、citrix，VMware处于服务器虚拟化领头羊地位。

Hive的数据管理：

（1）元数据存储

Hive 将元数据存储在 RDBMS 中，有三种模式可以连接到数据库：

Single User Mode：此模式连接到一个 In-memory 的数据库 Derby，一般用于 Unit Test。

Multi User Mode：通过网络连接到一个数据库中，这是最常用的模式。

Remote Server Mode：用于非 Java 客户端访问元数据库，在服务器端启动一个 MetaStoreServer，客户端则利用 Thrift 协议通过 MetaStoreServer来访问元数据库。

（2）数据存储

首先，Hive 没有专门的数据存储格式，也没有为数据建立索引，用户可以非常自由地组织 Hive 中的表，只需要在创建表的时候告诉 Hive 数据中的列分隔符和行分隔符，它就可以解析数据了。

其次，Hive 中所有的数据都存储在 HDFS 中，Hive 中包含4种数据模型：Table、External Table、Partition、Bucket。

Hive 中的 Table 和数据库中的 Table 在概念上是类似的，每一个 Table 在 Hive 中都有一个相应的目录来存储数据。例如，一个表 pvs，它在 HDFS 中的路径为：/wh/pvs，其中，wh 是在 hive-sitexml 中由 ${hivemetastorewarehousedir} 指定的数据仓库的目录，所有的 Table 数据（不包括 External Table）都保存在这个目录中。

Partition 对应于数据库中Partition 列的密集索引，但是 Hive 中 Partition 的组织方式与数据库中的很不相同。在 Hive 中，表中的一个 Partition 对应于表下的一个目录，所有的 Partition 数据都存储在对应的目录中。例如：pvs 表中包含 ds 和 city 两个 Partition，则对应于 ds = 20090801, city = US 的 HDFS 子目录为：/wh/pvs/ds=20090801/city=US；对应于 ds = 20090801, city = CA 的 HDFS 子目录为：/wh/pvs/ds=20090801/city=CA。

Buckets 对指定列计算 hash，根据 hash 值切分数据，目的是为了便于并行，每一个 Buckets对应一个文件。将 user 列分散至 32 个Bucket上，首先对 user 列的值计算 hash，比如，对应 hash 值为 0 的 HDFS 目录为：/wh/pvs/ds=20090801/city=US/part-00000；对应hash 值为 20 的 HDFS 目录为：/wh/pvs/ds=20090801/city=US/part-00020。

External Table 指向已经在 HDFS 中存在的数据，可以创建 Partition。它和 Table 在元数据的组织结构上是相同的，而在实际数据的存储上则有较大的差异。

在Table 的创建过程和数据加载过程（这两个过程可以在同一个语句中完成）中，实际数据会被移动到数据仓库目录中。之后对数据的访问将会直接在数据仓库的目录中完成。删除表时，表中的数据和元数据将会被同时删除。

External Table 只有一个过程，因为加载数据和创建表是同时完成的。实际数据是存储在 Location 后面指定的 HDFS 路径中的，它并不会移动到数据仓库目录中。

（3）数据交换

数据交换主要分为以下几个部分

你是黑网吧吗？ 软路由的话 用海蜘蛛 中文的很好配置。 软路由主机 去淘宝就可以了 几百块钱。
如果你是小网吧 无盘服务器 游戏服务器 服务器基本上是一体的。
无盘的好维护。
有盘的可以选择用还原卡。
无盘需要锐起31 还有一个游戏更新软件。 免费的我用迅闪。
至于服务器 我觉得装个PPs什么的就可以了 不用搞什么服务器 还得自己更新多麻烦。
具体说说你的带机量才好配置服务器。

遇到服务器故障，问题出现的原因很少可以一下就想到。我们基本上都会从以下步骤入手：

一、尽可能搞清楚问题的前因后果

不要一下子就扎到服务器前面，你需要先搞明白对这台服务器有多少已知的情况，还有故障的具体情况。不然你很可能就是在无的放矢。

必须搞清楚的问题有：

故障的表现是什么？无响应？报错？
故障是什么时候发现的？
故障是否可重现？
有没有出现的规律（比如每小时出现一次）
最后一次对整个平台进行更新的内容是什么（代码、服务器等）？
故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)
基础架构（物理的、逻辑的）的文档是否能找到
是否有监控平台可用 （比如Munin、Zabbix、 Nagios、 New Relic…
什么都可以）
是否有日志可以查看 （比如Loggly、Airbrake、 Graylog…）
最后两个是最方便的信息来源，不过别抱太大希望，基本上它们都不会有。只能再继续摸索了。

二、有谁在

代码如下:

$ w
$ last

用这两个命令看看都有谁在线，有哪些用户访问过。这不是什么关键步骤，不过最好别在其他用户正干活的时候来调试系统。有道是一山不容二虎嘛。（ne cook in
the kitchen is enough）

三、之前发生了什么

$
history查看一下之前服务器上执行过的命令。看一下总是没错的，加上前面看的谁登录过的信息，应该有点用。另外作为admin要注意，不要利用自己的权限去侵犯别人的隐私哦。

到这里先提醒一下，等会你可能会需要更新 HISTTIMEFORMAT
环境变量来显示这些命令被执行的时间。对要不然光看到一堆不知道啥时候执行的命令，同样会令人抓狂的。

四、现在在运行的进程是啥

代码如下:

$ pstree -a
$ ps aux

这都是查看现有进程的。 ps aux 的结果比较杂乱， pstree -a 的结果比较简单明了，可以看到正在运行的进程及相关用户。

五、监听的网络服务

代码如下:

$ netstat -ntlp
$ netstat -nulp
$
netstat -nxlp

我一般都分开运行这三个命令，不想一下子看到列出一大堆所有的服务。netstat -nalp倒也可以。不过我绝不会用 numeric 选项
（鄙人一点浅薄的看法：IP 地址看起来更方便）。

找到所有正在运行的服务，检查它们是否应该运行。查看各个监听端口。在netstat显示的服务列表中的PID 和 ps aux 进程列表中的是一样的。

如果服务器上有好几个Java或者Erlang什么的进程在同时运行，能够按PID分别找到每个进程就很重要了。

通常我们建议每台服务器上运行的服务少一点，必要时可以增加服务器。如果你看到一台服务器上有三四十个监听端口开着，那还是做个记录，回头有空的时候清理一下，重新组织一下服务器。

六、CPU 和内存

 代码如下:

$ free -m
$ uptime
$ top
$
htop

注意以下问题:

还有空余的内存吗 服务器是否正在内存和硬盘之间进行swap
还有剩余的CPU吗 服务器是几核的 是否有某些CPU核负载过多了
服务器最大的负载来自什么地方 平均负载是多少

七、硬件

代码如下:

$ lspci
$ dmidecode
$
ethtool

有很多服务器还是裸机状态，可以看一下：

找到RAID 卡 (是否带BBU备用电池)、 CPU、空余的内存插槽。根据这些情况可以大致了解硬件问题的来源和性能改进的办法。
网卡是否设置好
是否正运行在半双工状态 速度是10MBps 有没有 TX/RX 报错

八、IO 性能

代码如下:

$ iostat -kx 2
$ vmstat 2 10
$ mpstat
2 10
$ dstat --top-io --top-bio

这些命令对于调试后端性能非常有用。

检查磁盘使用量：服务器硬盘是否已满
是否开启了swap交换模式 (si/so)
CPU被谁占用：系统进程 用户进程 虚拟机
dstat 是我的最爱。用它可以看到谁在进行 IO： 是不是MySQL吃掉了所有的系统资源 还是你的PHP进程

九、挂载点 和 文件系统

 代码如下:

$ mount
$ cat /etc/fstab
$ vgs
$
pvs
$ lvs
$ df -h
$ lsof +D / / beware not to kill your box
/

一共挂载了多少文件系统
有没有某个服务专用的文件系统 (比如MySQL)
文件系统的挂载选项是什么： noatime
default 有没有文件系统被重新挂载为只读模式了？
磁盘空间是否还有剩余
是否有大文件被删除但没有清空
如果磁盘空间有问题，你是否还有空间来扩展一个分区？

十、内核、中断和网络

 代码如下:

$ sysctl -a | grep
$ cat
/proc/interrupts
$ cat /proc/net/ip_conntrack / may take some time on busy
servers /
$ netstat
$ ss -s

你的中断请求是否是均衡地分配给CPU处理，还是会有某个CPU的核因为大量的网络中断请求或者RAID请求而过载了？
SWAP交换的设置是什么？对于工作站来说swappinness 设为 60 就很好,
不过对于服务器就太糟了：你最好永远不要让服务器做SWAP交换，不然对磁盘的读写会锁死SWAP进程。

conntrack_max 是否设的足够大，能应付你服务器的流量
在不同状态下(TIME_WAIT, …)TCP连接时间的设置是怎样的？
如果要显示所有存在的连接，netstat 会比较慢， 你可以先用 ss 看一下总体情况。
你还可以看一下 Linux TCP tuning
了解网络性能调优的一些要点。

十一、系统日志和内核消息

 代码如下:

$ dmesg
$ less /var/log/messages
$
less /var/log/secure
$ less /var/log/auth

查看错误和警告消息，比如看看是不是很多关于连接数过多导致？
看看是否有硬件错误或文件系统错误
分析是否能将这些错误事件和前面发现的疑点进行时间上的比对。

十二、定时任务

 代码如下:

$ ls /etc/cron + cat
$ for user in
$(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done

是否有某个定时任务运行过于频繁
是否有些用户提交了隐藏的定时任务
在出现故障的时候，是否正好有某个备份任务在执行？

十三、应用系统日志

这里边可分析的东西就多了,
不过恐怕你作为运维人员是没功夫去仔细研究它的。关注那些明显的问题，比如在一个典型的LAMP（Linux+Apache+Mysql+Perl）应用环境里:

Apache & Nginx; 查找访问和错误日志, 直接找 5xx 错误, 再看看是否有 limit_zone 错误。
MySQL;
在mysqllog找错误消息，看看有没有结构损坏的表， 是否有innodb修复进程在运行，是否有disk/index/query 问题
PHP-FPM; 如果设定了 php-slow 日志, 直接找错误信息 (php, mysql, memcache, …)，如果没设定，赶紧设定。
Varnish; 在varnishlog 和 varnishstat 里, 检查 hit/miss比
看看配置信息里是否遗漏了什么规则，使最终用户可以直接攻击你的后端？
HA-Proxy;
后端的状况如何？健康状况检查是否成功？是前端还是后端的队列大小达到最大值了？

结论

经过这5分钟之后，你应该对如下情况比较清楚了：

在服务器上运行的都是些啥？
这个故障看起来是和 IO/硬件/网络 或者 系统配置 (有问题的代码、系统内核调优, …)相关。
这个故障是否有你熟悉的一些特征？比如对数据库索引使用不当，或者太多的apache后台进程。
你甚至有可能找到真正的故障源头。就算还没有找到，搞清楚了上面这些情况之后，你现在也具备了深挖下去的条件。继续努力吧！

---