Etcd是什么

etcd 是一个高分布式 key/value 存储服务。类似zookeeper或者其他分布式kv存储。不同的是具有http api可以直接操作kv。

功能：

程序和服务可以通过 etcd 共享信息或做服务发现。

在默认的配置下，etcd 使用系统中的两个端口：4001和7001，其中4001提供给外部应用程序以HTTP+Json的形式读写数据，而7001则用作在每个 etcd 之间进行数据同步。用户更可以通过配置 CA Cert让 etcd 以 HTTPS 的方式读写及同步数据，进一步确保数据信息的安全性。

简单：支持 curl 方式的用户 API (HTTP+JSON)
安全：可选 SSL 客户端证书认证
快速：单实例可达每秒 1000 次写操作
可靠：使用 Raft 实现分布式

Apache Mesos能够成为最优秀的数据中心资源管理器的一个重要功能是面对各种类型的应用，它具备像交警一样的疏导能力。本文将深入Mesos的资源分配内部，探讨Mesos是如何根据客户应用需求，平衡公平资源共享的。在开始之前，如果读者还没有阅读这个系列的前序文章，建议首先阅读它们。第一篇是Mesos的概述，第二篇是两级架构的说明，第三篇是数据存储和容错。

我们将探讨Mesos的资源分配模块，看看它是如何确定将什么样的资源邀约发送给具体哪个Framework，以及在必要时如何回收资源。让我们先来回顾一下Mesos的任务调度过程：

从前面提到的两级架构的说明一文中我们知道，Mesos Master代理任务的调度首先从Slave节点收集有关可用资源的信息，然后以资源邀约的形式，将这些资源提供给注册其上的Framework。 继续阅读 →

持久化存储的问题

正如我在前文中讨论过的，使用Mesos的主要好处是可以在同一组计算节点集合上运行多种类型的应用程序（调度以及通过Framework初始化任务）。这些任务使用隔离模块（目前是某些类型的容器技术）从实际节点中抽象出来，以便它们可以根据需要在不同的节点上移动和重新启动。

由此我们会思考一个问题，Mesos是如何处理持久化存储的呢？如果我在运行一个数据库作业，Mesos如何确保当任务被调度时，分配的节点可以访问其所需的数据？如图所示，在Hindman的示例中，使用Hadoop文件系统（HDFS）作为Mesos的持久层，这是HDFS常见的使用方式，也是Mesos的执行器传递分配指定任务的配置数据给Slave经常使用的方式。实际上，Mesos的持久化存储可以使用多种类型的文件系统，HDFS只是其中之一，但也是Mesos最经常使用的，它使得Mesos具备了与高性能计算的亲缘关系。其实Mesos可以有多种选择来处理持久化存储的问题：

• 分布式文件系统。如上所述，Mesos可以使用DFS（比如HDFS或者Lustre）来保证数据可以被Mesos集群中的每个节点访问。这种方式的缺点是会有网络延迟，对于某些应用程序来说，这样的网络文件系统或许并不适合。
• 使用数据存储复制的本地文件系统。另一种方法是利用应用程序级别的复制来确保数据可被多个节点访问。提供数据存储复制的应用程序可以是NoSQL数据库，比如Cassandra和MongoDB。这种方式的优点是不再需要考虑网络延迟问题。缺点是必须配置Mesos，使特定的任务只运行在持有复制数据的节点上，因为你不会希望数据中心的所有节点都复制相同的数据。为此，可以使用一个Framework，静态地为其预留特定的节点作为复制数据的存储。

  

• 不使用复制的本地文件系统。也可以将持久化数据存储在指定节点的文件系统上，并且将该节点预留给指定的应用程序。和前面的选择一样，可以静态地为指定应用程序预留节点，但此时只能预留给单个节点而不是节点集合。后面两种显然不是理想的选择，因为实质上都需要创建静态分区。然而，在不允许延时或者应用程序不能复制它的数据存储等特殊情况下，我们需要这样的选择。

Mesos项目还在发展中，它会定期增加新功能。现在我已经发现了两个可以帮助解决持久化存储问题的新特性：

• 动态预留。Framework可以使用这个功能框架保留指定的资源，比如持久化存储，以便在需要启动另一个任务时，资源邀约只会发送给那个Framework。这可以在单节点和节点集合中结合使用Framework配置，访问永久化数据存储。关于这个建议的功能的更多信息可以从此处获得。
• 持久化卷。该功能可以创建一个卷，作为Slave节点上任务的一部分被启动，即使在任务完成后其持久化依然存在。Mesos为需要访问相同的数据后续任务，提供在可以访问该持久化卷的节点集合上相同的Framework来初始化。关于这个建议的功能的更多信息可以从此处获得。

继续阅读 →

Mesos流程

接着上一篇文章说。并结合前述的加州大学伯克利分校的白皮书以及Apache Mesos网站，开始我们的讲述：

我们来研究下上图的事件流程。上一篇谈到，Slave是运行在物理或虚拟服务器上的Mesos守护进程，是Mesos集群的一部分。Framework由调度器（Scheduler）应用程序和任务执行器（Executor）组成，被注册到Mesos以使用Mesos集群中的资源。

• Slave 1向Master汇报其空闲资源：4个CPU、4GB内存。然后，Master触发分配策略模块，得到的反馈是Framework 1要请求全部可用资源。
• Master向Framework 1发送资源邀约，描述了Slave 1上的可用资源。
• Framework的调度器（Scheduler）响应Master，需要在Slave上运行两个任务，第一个任务分配<2 CPUs, 1 GB RAM>资源，第二个任务分配<1 CPUs, 2 GB RAM>资源。
• 最后，Master向Slave下发任务，分配适当的资源给Framework的任务执行器（Executor）,接下来由执行器启动这两个任务（如图中虚线框所示）。 此时，还有1个CPU和1GB的RAM尚未分配，因此分配模块可以将这些资源供给Framework 2。

继续阅读 →

Mesos，一个Apache开源项目。为什么我对Mesos如此兴奋？回想x86虚拟化之初对数据中心曾经的承诺：通过增加服务器利用率使其更高效，通过从物理基础架构抽象应用使其更敏捷。虽然收获颇丰，但是以虚拟机为单位，粒度仍不够精细，如果应用程序都过于庞大，那就难以充分实现这一承诺。如今，飞速发展的容器技术、分布式应用程序和微服务技术正悄然改变着我们对数据中心的运行和管理方式。

试想，可否整合数据中心中的所有资源，并将它们放在一个大的虚拟池里，代替单独的物理服务器；然后开放诸如CPU、内存和I/O这些基本资源而不是虚拟机？同样，可否把应用程序拆分成小的、隔离的任务单位，从而根据数据中心应用的需求，从虚拟数据中心池中动态分配任务资源？就像操作系统将PC的处理器和RAM放入资源池，使其可以为不同的进程协调分配和释放资源。进一步讲，我们可以把Mesos作为操作系统内核，然后将数据中心看为PC。这也是正是我想说的：Mesos正在改变数据中心，它让真正的SDDC成为现实。

继续阅读 →

XenServer Yum 安装软件
enServer，基于CnetOS，精简部分功能，加入了思杰自己的虚拟化技术，形成了一个强大的虚拟机运行管理系统（描述可能不恰当，但是你们懂的）。

熟悉CentOS的都知道，在其上安装软件那是极为方便的。对，就是Yum神奇！既然XenServer是基于CentOS，那么按理说在其上安装软件（比如Vim、MySQL-Server、编译软件需要的依赖包）也应该是很方便的.
事实总是和理想相违背的，要现实一点。在XenServer里，虽有Yum，但是思杰只有一个单一的yum库（他们自己的），只用于安装Base（基础）文件。找度娘，基本千篇一律，说是把那个啥 ennabled=0 改成 enabled=1。
试过的都知道，压根不行，自己也不试一下，就抄来一转发。

Step1：查看XenServer Yum 启用/禁用的库
#yum repolist enabled
可以看到默认只有 citrix 库被启用
#yum repolist disabled
Step2：Yum安装你所需的软件
yum –enablerepo=base ––isablerepo=citrix install vim-enhanced
yum –enablerepo=base –disablerepo=citrix install dmidecode
就是这条简单的命令，别问为什么，我也不知道，好用就行。如果要安装其他软件，类似地
#yum –enablerepo=base –disablerepo=citrix install 软件名

Step3：永久改变Yum配置（不推荐）
#sed -i -e “s/enabled=0/enabled=1/” /etc/yum.repos.d/CentOS-Base.repo
之后Yum安装软件，就直接 yum install 软件名
不过，不建议这样做.

xe host-list
获取到host的uuid
然后列出现有的sr和pbd
xe pbd-list
xe sr-list
xe pbd-list
xe pbd-unplug uuid=ee19ba75-f56f-332b-3496-7b0c0d1e9a22
xe pbd-destroy uuid=ee19ba75-f56f-332b-3496-7b0c0d1e9a22
xe sr-destroy uuid=ee19ba75-f56f-332b-3496-7b0c0d1e9a22
xe sr-list
xe sr-forget uuid=5571501c-adf7-7bb7-0ac2-6ed35f97a103
xe sr-create host-uuid=2159b4ad-47cb-4b91-a879-3f2bbb2023b0 content-type=user type=lvm device-config:device=/dev/sda3 shared=false name-label=”Localstorage” sm-config:allocation=thin

在虚拟化和云计算以及容器时代，我们将很多物理服务器所跑的应用全部迁移至以xen虚拟化私有云中。这时候会面临物理服务器迁移到虚拟服务器的问题。迁移windows到是xencover可以干，但是linux呢，网络上很多人都没有说。这里我简单介绍下迁移流程：

1.使用clonezilla live cd启动物理服务器

2.使用网络方式挂在nas

3.使用dd将硬盘block导到nas上

4.启动vm即可！

来点图：

Step 1 use “clonezilla Live CD”
Step 2 boot using Clonezilla Live CD
Step 3 Choose language in Clonezilla live
Step 4 Keyboard selection in clonezilla live
Step 5 Enter clonezilla or shell command (choose shell command)
Step 6 Choose option “2″
Step 7 You’ll get “$” prompt
Step 8 $ sudo bash
Step 9 # ifconfig eth0 XXX.XXX.XXX.XXX
Step 10 # passwd (change root passwd)
Step 11 # /etc/init.d/ssh restart
Step 12 Create new VM with HDD/CPU/MEM
Step 13 Boot VM with Clonezilla Live CD
Step 14 Follow above 11 step
Step 15 # dd if=/dev/sda |gzip -c | ssh root@target ip address ‘gzip -d | dd of=/dev/sda’
Step 16 reboot VM