你回老家快一个月了，爸爸一个人在家过周末真的很无聊。。。
快点回来吧
最近跟你视频聊天，每次你都不太高兴，不愿意跟爸爸妈妈讲话，我们都知道，你是生气了
因为爸爸妈妈让你一个人跟爷爷回老家了，你以为爸爸妈妈不要你了
其实我们也不想让你回老家的，但是奶奶种的西瓜没人收啊，爸爸也劝了她很多次，可是她就是不听，明年肯定不让她种了
其实你在家玩的还是很好的，就是脾气不好，老喜欢欺负比你小的小朋友，这也不是一天两天了，这可不是个好习惯，一定要改掉
每次视频，爷爷奶奶都会告你的状，说你又跟谁打架了，又怎么不听话了，又怎么不吃饭了
你每次都很生气，其实爷爷奶奶是逗你玩呢
不过你也够坏的，所有的东西都是你的，别人不能跟你抢，否则就动手打人，这个坏习惯一直改不掉
你在家还叫姑姑叫妈妈，不让妹妹叫，爸爸知道你那是想妈妈了，就像当年你馨怡姐姐跟你这么大的时候一样，我和你妈妈回老家，她在姥姥家，也是一会儿妗妗一会儿妈妈、一会儿舅舅一会儿爸爸的
据爷爷说你现在又黑又瘦，可怜的娃儿，爸爸妈妈也不想让你回去，可是有些事情是没办法的，只能委屈你了
人生有很多无奈，只能忍受，等你长大了就会有体会
下面附上你的精彩表演：
cinder服务提供了几个transfer-*接口，用来支持租户间转移卷功能：
|
1 2 3 4 5 6 |
~$ cinder help | grep transfer transfer-accept Accepts a volume transfer. transfer-create Creates a volume transfer. transfer-delete Undo a transfer. transfer-list List all the transfers. transfer-show Show details about a transfer. |
大概流程是，租户A的卷vol-1，可以通过transfer-create接口创建一个转移操作流，并返回一个接收卷所需的验证码，然后可以通过transfer-list、transfer-show可以看到这个操作流，如果租户A在卷未被接收前反悔了，还可以通过transfer-delete接口删除这个操作流。
目标租户B，可以通过transfer-accept接口接收这个卷vol-1，接收完之后，租户A就看不到这个卷vol-1了，而租户B则可以看到并使用它。
命令行操作流程大概如下，首先使用租户A的账号执行：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
~$ cinder create --display-name vol-1 10 # 租户A创建一个卷 +---------------------+--------------------------------------+ | Property | Value | +---------------------+--------------------------------------+ | attachments | [] | | availability_zone | zw | | bootable | false | | created_at | 2015-07-06T08:18:14.214559 | | display_description | None | | display_name | vol-1 | | id | ec1323d5-467b-4ddb-a3fb-352936e688e8 | | metadata | {} | | size | 10 | | snapshot_id | None | | source_volid | None | | status | creating | | volume_type | None | +---------------------+--------------------------------------+ |
|
1 2 3 4 5 6 7 8 9 10 |
~$ cinder transfer-create --display-name transfer-to-project-b vol-1 # 租户A创建卷转移操作流 +------------+--------------------------------------+ | Property | Value | +------------+--------------------------------------+ | auth_key | 289fa570e6dc4626 | # 接收卷验证码，只在创建操作流时返回一次 | created_at | 2015-07-06T08:19:07.687577 | | id | c7ff2c3c-f051-480e-94be-bef91d164a73 | # 卷转移操作流UUID | name | transfer-to-project-b | | volume_id | ec1323d5-467b-4ddb-a3fb-352936e688e8 | +------------+--------------------------------------+ |
|
1 2 3 4 5 6 |
~$ cinder transfer-list +--------------------------------------+--------------------------------------+-----------------------+ | ID | Volume ID | Name | +--------------------------------------+--------------------------------------+-----------------------+ | b41c6e3a-6db4-4d82-9466-79ecce569fcf | 7c811013-9546-4059-9084-4f1a70bc1fea | transfer-to-project-b | +--------------------------------------+--------------------------------------+-----------------------+ |
|
1 2 3 4 5 6 7 8 9 |
~$ cinder transfer-show c7ff2c3c-f051-480e-94be-bef91d164a73 +------------+--------------------------------------+ | Property | Value | +------------+--------------------------------------+ | created_at | 2015-07-06T08:19:07.000000 | | id | c7ff2c3c-f051-480e-94be-bef91d164a73 | | name | transfer-to-project-b | | volume_id | ec1323d5-467b-4ddb-a3fb-352936e688e8 | +------------+--------------------------------------+ |
然后更换到租户B的账号下执行：
|
1 2 3 4 5 6 7 8 |
~$ cinder transfer-accept c7ff2c3c-f051-480e-94be-bef91d164a73 289fa570e6dc4626 # 租户B接收卷 +-----------+--------------------------------------+ | Property | Value | +-----------+--------------------------------------+ | id | c7ff2c3c-f051-480e-94be-bef91d164a73 | | name | transfer-to-project-b | | volume_id | ec1323d5-467b-4ddb-a3fb-352936e688e8 | +-----------+--------------------------------------+ |
注意：如果在租户B下执行transfer-list、transfer-show操作，是看不到租户A创建的卷转移操作流的，如果租户B具有管理员权限，则可以根据卷转移操作流UUID来通过transfer-show看到操作流详情。
租户B接收卷之后，就可以通过cinder list、cinder show看到卷vol-1了，租户A则看不到了。
整个流程的代码实现也比较简单，主要就是：
1、检查并预留租户B的配额（类似创建一个新卷）
2、修改卷所属的租户和用户
3、减少租户A的配额（类似删除一个卷）
当然上面这部分不是本文的重点，接下来是考虑在nova服务中实现云主机的转移功能。
主要说下为啥要做这个功能？
最终目标是让自动部署平台可以快速的扩容，具体使用场景是，自动部署平台使用的docker容器是在云主机中运行的，在集群资源利用率达到某个预设值后，可以快速的水平扩容出去，比如新增一批docker容器来运行各种服务（可能对应的是一批kubernetes的pod，也就是多个docker实例），这里的“快速”是要尽量做到秒级扩容，但是目前我们创建一台本地实例存储盘启动的云主机，如果目标计算节点上没有base镜像缓存，可能需要几分钟的时间来下载base镜像，然后创建云主机（几秒钟），最后启动云主机（几十秒），即使有base镜像缓存，也需要几十秒到1分钟以上的等待时间（创建+启动）才能通过自动部署平台的agent开始在云主机内部执行部署操作，这个耗时情况目前看来自动部署平台是不能接受的，需要实现一个云主机资源池，来随时加入到集群中作为docker宿主机，如果云主机不支持在租户间转移，那么这个资源池只能是每个租户维护一个，可想而知，会有很多资源浪费情况，如果资源池能做到平台级别，整个平台维护一个，则会节约很多。
nova本身并未实现该功能，所有功能都需要我们自己开发实现，并且只是给内部PAAS服务使用，因此实现和操作流程越简单越好，不需要跟cinder中的卷转移一样，还要create然后accept，只需要实现一个transfer接口就好了，直接把云主机转移到指定租户（当然需要操作调用方有特定权限去执行该操作），并且修改掉两个租户的配额。
另外要说明的是租户私有网问题，由于租户的私有网是不互通的，所以云主机资源池中的云主机不能绑定私有网port，需要等待云主机从资源池中分配出去之后，再根据云主机真实所属的租户来动态挂载私有网等网络类型的port到云主机，达到网络连通的目的。
但是目前看起来如果创建云主机时不指定network id，会返回400错误，这个还需要进一步分析解决。
1、通过扩展api，增加一个action，比如叫“transferInstance”，具体扩展方法可以参考我们的commit 2ed5a96089eb3fd57efb4fa88b9956ec288e539c，patch下载：extend-vnc-password.tar。
API URL：POST http://nova/v2/981f3e7cdba14f0ab769d3325b931838/servers/73cae225-7a96-4d4f-836c-931d8be77261/action
参数大概为：
|
1 2 3 4 5 6 |
{ "transferInstance": { "tenant_id": "abcdefg", # 新租户的id "user_id": "123456" # 新用户的id } } |
2、在nova/netease/compute/api.py中新增transfer_instance方法，实现修改转移前后两个租户的配额，以及nova db中instances表中instance所属project_id和user_id
3、返回结果给调用方（成功200，失败其他错误码，比如配额不足413，目标云主机或租户找不到404等）
目前必须带私有网创建云主机，如果要改掉这一限制，整个创建云主机的流程都需要修改，改动比较多，对现有功能影响也比较大，不建议修改，可以通过创建后卸载私有网操作来规避这个问题，大致流程如下：
1、创建云主机，并且包含了一个私有网port
2、创建完毕后，从云主机上卸载私有网port
3、放入云主机资源池，之后按需转移云主机到新租户下
4、在新租户内创建新的私有网port并挂载到云主机
这一流程潜在的问题包括：
1、私有网挂载卸载操作之前没有测试过，默认都是与云主机生命周期绑定的，需要进一步测试验证相关流程和网络连通性
2、挂载私有网port后，要多久网络才能连通也需要测试，如果耗时较长，甚至比新创建云主机还要耗时，那么这个方案是不可接受的
3、卸载完私有网port之后，要多久才能挂载新的port到云主机，以防止并发问题（主要是指qemu进程和云主机内部的pci设备hotplug模块两个方面）导致的其他问题（比如看不到网卡、网络不通等）
4、可能需要自动部署平台增加从云主机资源池中选择被转移云主机的逻辑，比如先进先出方式，而不是随机选择，以防止刚加入池子的云主机被转移，导致的port挂卸载并发问题
说明：上述流程待POC验证
明天就是7月6号了，提前祝儿子生日快乐，永远快乐！
时间都去哪儿了？
转眼间儿子都三周岁了，感觉都还没怎么陪他玩儿，他就长大了。
刚生下来的时候那么小，现在都95公分高，28斤重了。
现在的问题是，儿子不喜欢跟小女孩一起玩，这个问题急需解决啊，谈恋爱要从娃娃抓起，这是必须的！
周末两天都下雨，在家窝了两天，也没带儿子出去玩，好可惜。
生日礼物还是妈妈今天下班之后顺路买的，白天没睡觉，困了也不睡，就为了等妈妈带礼物回来。。。
8号就要跟爷爷一起回老家了，估计至少要一个月之后才能回来，真是舍不得，但也没办法，奶奶那边已经催了好几次了，爷爷也是天天心急火燎的，一天都呆不下去了，要不是因为要等着幼儿园报名、录取结果出来，肯定早回去了。。。
幼儿园报名也不容易啊，公立的收的少，户口2013年之前的才有机会，私立的人多，还要托人，还好找到了关系，花了点钱，总算是报上了。
总之，祝儿子回家一路顺风，以后的人生顺风顺水、平安健康！
首先说明，本博客基于LAMP+wordpress构建
Linux备份MySQL和wordpress目录，采用crontab定时任务完成，脚本如下：
|
1 2 |
xxx@myblog:~# cat /etc/cron.d/blog 35 2 */1 * * root /path/to/blog_backup.sh |
然后加入定时任务：
|
1 2 |
xxx@myblog:~# crontab /etc/cron.d/blog xxx@myblog:~# crontab -l<br>35 2 */1 * * root /path/to/blog_backup.sh |
每天凌晨2点35分自动执行备份脚本，备份脚本内容如下（设置可执行权限）：
|
1 2 3 4 5 6 |
#! /bin/bash # mysql backup mysqldump -uuser -ppassword mydb > /path/to/blog-backup/mydb`date +%Y%m%d`.sql # blog backup tar Pcf /path/to/blog-backup/www`date +%Y%m%d`.tar /path/to/www |
备份完毕之后，通过rsync服务同步到windows机器上，配置如下：
Linux服务端：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
xxx@myblog:~# ll /etc/rsync/ total 12 -rw------- 1 root root 24 Jun 18 12:01 blog.pas -rw-r--r-- 1 root root 735 Jun 18 11:13 rsyncd.conf -rw------- 1 root root 29 Jun 18 12:01 rsync.pas xxx@myblog:~# cat /etc/rsync/blog.pas rsync-blog-password root@myblog:~# cat /etc/rsync/rsync.pas blog:rsync-blog-password xxx@myblog:~# cat /etc/rsync/rsyncd.conf # Minimal configuration file for rsync daemon # See rsync(1) and rsyncd.conf(5) man pages for help # This line is required by the /etc/init.d/rsyncd script pid file = /var/run/rsyncd.pid lock file = /var/lock/rsyncd.lock port = 873 address = 10.0.0.17 uid = root gid = root use chroot = no read only = no #limit access to private LANs hosts allow=10.0.0.9 hosts deny=* max connections = 32 motd file = /etc/rsync/rsyncd.motd #This will give you a separate log file log file = /var/log/rsync/rsync.log log format = %t %a %m %f %b syslog facility = local3 timeout = 300 [blog] path = /path/to/blog-backup list = no ignore errors auth users = blog secrets file = /etc/rsync/rsync.pas #comment = blog backup dir #exclude = |
然后rsync –daemon –config=/etc/rsync/rsyncd.conf打开rsync服务端守护进程。
Windows客户端：
下载安装cwRsyncServer_4.0.6_Installer（从本站下载请点这里 ：cwRsyncServer_4.0.6_Installer），
编写rsync客户端同步bat批处理脚本：
|
1 2 |
cd /d c:\Program Files (x86)\ICW\Bin rsync.exe -vzrtopgu --progress --delete --port=873 blog@10.0.0.17::blog /cygdrive/d/blog-backup/blog-backup < blog.pas |
其中blog.pas为密码文件，放在目录
|
1 |
c:\Program Files (x86)\ICW\Bin |
内容为：
|
1 |
rsync-blog-password |
然后把blog.bat加入到windows的任务计划程序，我从windows7任务计划程序导出的任务配置为：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
<?xml version="1.0" encoding="UTF-16"?> <Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task"> <RegistrationInfo> <Date>2015-06-18T11:58:46.521</Date> <Author>xxx-PC\xxx</Author> </RegistrationInfo> <Triggers> <CalendarTrigger> <StartBoundary>2015-06-18T02:58:16</StartBoundary> <Enabled>true</Enabled> <ScheduleByDay> <DaysInterval>1</DaysInterval> </ScheduleByDay> </CalendarTrigger> </Triggers> <Principals> <Principal id="Author"> <UserId>xxx-PC\xxx</UserId> <LogonType>InteractiveToken</LogonType> <RunLevel>LeastPrivilege</RunLevel> </Principal> </Principals> <Settings> <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy> <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries> <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries> <AllowHardTerminate>true</AllowHardTerminate> <StartWhenAvailable>false</StartWhenAvailable> <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable> <IdleSettings> <StopOnIdleEnd>true</StopOnIdleEnd> <RestartOnIdle>false</RestartOnIdle> </IdleSettings> <AllowStartOnDemand>true</AllowStartOnDemand> <Enabled>true</Enabled> <Hidden>false</Hidden> <RunOnlyIfIdle>false</RunOnlyIfIdle> <WakeToRun>false</WakeToRun> <ExecutionTimeLimit>P3D</ExecutionTimeLimit> <Priority>7</Priority> </Settings> <Actions Context="Author"> <Exec> <Command>D:\blog-backup\blog.bat</Command> </Exec> </Actions> </Task> |
每天凌晨2点58分执行一次rsync同步命令，注意这个时间是在Linux服务端执行备份脚本之后的，便于及时同步数据。
同步完毕之后，还有一步可选操作，也即同步到云盘（360云盘或者百度云盘），备份数据会更加安全（前提是你的云盘账号不被盗走。。。），设置步骤如下：
下载安装云盘客户端，360或者百度都可以，打开客户端，按如下步骤设置即可：
首先说明下写这篇文章的背景
某厂的云计算项目始于2012年，当时的OpenStack才刚刚起步，而我那时候还在老东家HW搞底层虚拟化平台（Xen及关联的qemu、libvirt等），连OpenStack都没听说过，只知道eucalyptus这个玩意儿（是我们开发的虚拟化平台的上层客户），听说最多的是VMware和aws，稍微扯远了，回到OpenStack项目，当时某厂也在调研各种云平台和虚拟化技术，由于某厂属于互联网公司（至少他们自己这么认为），自认为还有一些技术实力（即使现在没有，也是可以从其他厂里挖墙脚嘛），所以肯定不会考虑商业平台比如VMware，或者其他公有云、私有云解决方案提供商（或者说托管云），全部使用开源组件，构建自己的云计算平台是基本要求。
据说当时云管理平台方面对比了OpenStack、cloudstack、eucalyptus等主流云平台，底层虚拟化平台主要对比了Xen和KVM（说实话开源的虚拟化技术也没有其他的了），最终选择了OpenStack+KVM技术，目前看来还是十分明智的，对比其他云平台，要么半死不活、要么作价卖掉，只有OpenStack发展势头愈发迅猛（当然很多人认为目前容器技术如docker有取而代之的趋势，但我并太认同，二者的适用场景明显不太一样，后续有时间再开一个页面详细叙述吧），底层虚拟化技术Xen也日暮西山，支持的开源大厂也寥寥无几，基本可以忽略了，KVM借力Linux内核，已经逐步被各种企业厂商接受。
从上面的背景描述可以看出，某厂的领导还是很有眼光的，毕竟都是技术出身一步一步做到领导职位的，这点我还是相当佩服的。
OpenStack+KVM，很完美的搭配，凡事都有个演进过程，某厂也不例外，OpenStack Essex版本是第一个上线版本，当时还没有cinder、neutron这两大组件，只有最基础的计算服务nova组件，很多人都认为云计算服务重要性（难度）排名为：网络40%、存储40%，计算只占20%，我也是很赞同这个观点的，但是前提是计算服务已经稳定下来的情况下，如果计算服务还有一堆问题没解决，其他两大服务就别想玩好，从运维方面来说，云计算三分开发七分运维，也符合442这种重要性或者难度排名。
又扯远了，当时主要用了keystone、glance、nova服务，包含nova-network，没有用nova-volume（cinder服务的前身），而是自己开发的一套块存储服务，对象存储用的也是某厂自己已有的服务，这里主要讨论块存储这部分的演进过程。
刚开始的时候某厂的块存储是模仿aws的EBS服务来构建的，而不是为了搭配nova-volume，这一决定给后续整个云平台的发展带来了较大的障碍，列举出来有如下几个潜在问题：
上面第三点又扯远了，但确实是很现实的问题，我相信也是很多其他厂遇到的问题，为啥会出现这种困境？我个人理解其中一个原因就是自己设计了一个闭源系统，并且人员储备不足（或者说来不及储备，带头大哥就被隔壁厂挖走了。。。跟隔壁老王有一拼了。。。），后面招人维护或者改进会更加难上加难，上面第三点也简单描述了一些原因。假设换成使用的是业界主流开源系统，这种情况肯定会大有不同，毕竟码农也想给自己贴金，以期提高卖身价钱，如果是一个闭源系统，你做的再好、再牛逼，也只是服务于一个很小的范围（某个厂的内部、某个厂的特定客户，除非你能做到微软、VMware这种世界一流的平台），想要用这种系统来作为跳槽的垫脚石，目标公司的认可度肯定大打折扣，至少很少有机会被其他厂主动挖墙脚，主动和被动看起来结果差不多，但是待遇就不一样了，一个让你自己提要求、一个是让你不敢提要求。
但是换做开源系统，你贡献的一个bug修复，一个小功能，都可能让全世界的所有使用该系统的厂家受益，你的名字也会被全世界关心这个bug或者功能的码农关注甚至膜拜，这对码农（一般都是宅男，没机会被世人关注，只能躲在阴暗角落里偷偷的边抹泪边码代码）来说是非常难得扬名立万的机遇，如果能成为某个流行的开源系统的重要代码贡献者、甚至核心开发人员，基本可以与金榜题名相比了，对码农来说简直可以说是无上荣耀，足以光宗耀祖，养家糊口更是不在话下，带领全家奔小康也是小菜一碟、信手拈来、稀松平常！各种公司都会在各种场合通过各种方式向你伸出橄榄枝，想要挖你过去，待遇足以让你心动。
采用流行开源系统还有一个好处，人员储备几乎可以不用太过担心，毕竟一抓一大把搞这方面的人，想找核心贡献者很难（这要看你敢不敢开价了），想找入门级、熟练级的肯定不难，稍加指导即可给你卖力干活了，他们也没有后顾之忧，毕竟自己的能力没有断层，还是延续专长的方向，即使在你这混不下去，还可以凭自己的本事找到合适的接盘厂，不至于家里老婆孩子喝西北风。
其他开源的好处就不多说了，已经扯得远的没边了。。。
一开始的时候，挂卸载卷操作是云硬盘服务组，通过自己在计算节点上的agent调用libvirt接口来做的，也就是用户挂卸载卷都是云硬盘组单独处理的，云硬盘还要调用nova接口查询虚拟机状态，计算服务nova等根本不清楚也不参与这个流程，然后各种并发问题、虚拟机迁移问题等等就接踵而来，靠云硬盘服务肯定搞不定，靠nova服务也不行，因为他管不到云硬盘。想想都觉得不靠谱。
后来在计算服务组相关开发的推动下，改为使用nova的挂卸载卷接口来执行操作，好了很多，毕竟nova控制了这个流程，虽然多加了一部分云硬盘的驱动代码来跟云硬盘api交互，还对nova本身的代码做了一些改动，维护有点困难，至少某些功能可以做起来了，大部分问题也解决掉了，虽然创建删除卷等操作还是要调用云硬盘api，顺便说了下，为了适配这个改动，云硬盘还开发了一个代理程序，用于接口转换，让上层用户平滑过渡。
后来的后来，也就是平台上线近两年后，云硬盘和计算服务的开发已经对这种模式吐槽到不行了，这个时候的cinder服务也已经发展到了Havana版本（某厂的其他服务也已经升级到这个版本），社区对cinder的稳定性也逐步认可，也经过了其他厂的验证，某厂也开始考虑把云硬盘服务接入过来，作为cinder的一种后端存储方案，为此开发了专用的cinder driver，基本也就是把之前的nova里面的驱动改吧改吧挪到cinder里面，这样nova服务关于卷的操作就完全兼容了OpenStack社区实现，基本不需要做任何改动（除了部分功能增强，这部分跟这次改进没有联系），为后续nova服务的顺利升级、新功能的支持打下了良好基础。
经过这次改进，计算服务和存储服务的交互就只集中在cinder服务的一个驱动模块了，大大简化了沟通难度，后续两个服务各司其职，架构清晰，有什么要求只要给存储后端提需求即可，cinder服务成了需求方，功能开发更加顺利（之前还要两个服务讨论清楚怎么分工，怎么合作），沟通成本大降。
改完之后，所有的问题都集中在了存储后端本身，各种云计算服务的基础功能，比如从云硬盘启动虚拟机（或者叫从块设备启动虚拟机，boot from volume），在线迁移虚拟机，云硬盘快照，从快照恢复虚拟机，等功能都需要云硬盘后端提供技术支持，但很遗憾，这些都不能做到。所以就面对第三次改进还是直接更换技术方案的严峻问题。
首先要把各种功能补齐，下面列举一些：
再说下性能问题，或者说用户体验问题，主要是指打快照耗时、快照恢复耗时、从云硬盘虚拟机启动等操作的耗时：
上面吐槽了太多某厂的存储方案，下面简单看下其他采用OpenStack云平台的厂商是怎么解决这些槽点的，据我了解，主要有如下几种方案：
我在此推荐统一存储方案Ceph，理由如下：
Ceph也不是完美无缺，从各个渠道你可以得知，它也是各种性能、功能问题缠身，但我想强调的是，他是主流开源技术，尤其是配合OpenStack，简直是绝配，一个系统搞定三种存储方式（文件、块、对象），尤其是数据零拷贝这一优势，对系统的压力大减，用户体验改进十分明显。有人说10个OpenStacker9个Cepher，虽然有点夸张，但是至少表明这是一种趋势。
Ceph我也没有深入研究过，但就是对他莫名的感兴趣，想尝试一番，可以这么说，他对我的吸引力已经超出了docker。
下面列出一些我看到的Ceph的文章，供大家参考：
最后在罗嗦几句，如果某厂从自研方案切换到Ceph，要付出哪些代价？
切换带来的好处显而易见，上面的槽点都能一一解决，而且是不费吹灰之力。。。
其实云硬盘服务的开发人员也是支持切换到Ceph的，谁不想跟着开源潮流走？谁想费时费力的开发半年，做出来一套很矬的系统，还不如开源实现来的好？
只是某厂的领导们还没下决心做这件事情，怕风险太大，砸了云计算平台的招牌，这也是可以理解的，但通过上面的切换流程，其实风险没那么大的。
我这里只针对Android手机进行说明，苹果手机买不起，没用过，不敢妄言，不过据说有iCloud这个牛X工具，可以搞定一切，用iPhone的朋友可以试试看。
经常听到朋友同学等很多人说，我的手机丢了、坏了，通讯录没了，让我把联系方式发一下给他。
我也换过几个手机，也丢过一个，还刷机过很多次，但是我的通讯录从来没有丢过，最多也就是通讯录更新不及时，很多人的联系方式都不准确而已。
怎么做才能保证通讯录不会丢？
我是采用了上面的三种方法来备份的，所以即使我的电脑坏了、丢了，手机坏了、丢了、刷机了，我的通信录也还有备份。
当你更换手机，或者刷机后，通信录是空的，可以通过上面的备份恢复回来，
需要注意的是，采用手机自带云备份和第三方云备份，需要有用户名密码在登录时使用，所以你一定要记住他们，不然之后是没办法恢复的，尤其是你想恢复可能是很久以后的事情了。
照片视频一般为手机和相机拍出来的，手机又分为我自己的和老婆的，拍出来的照片视频一般比较多，所以比较占空间，如果放到QQ空间，或者博客相册，好几百G的量，很难存的下，即使保存了，也是压缩过的，分辨率太低了，不忍直视。尤其是视频，除了优酷之类的网站，根本没地方存，存储空间倒是不限制，只是质量就不敢恭维了，而且优酷之类的网站，会根据视频的热度分配带宽，私人视频，播放的时候，不但有超长的广告，还会十分卡顿，不能忍啊！
为此，我采用两种备份手段：
备份完之后，还需要定期整理，不然乱成一坨，若干年以后怎么看？
整理我一般是一两个月做一次，每次整理，是把移动硬盘里面的照片视频，上传到360云盘和百度云盘，然后把360云盘自动备份的照片视频，下载到移动硬盘里面，并且上传到百度云盘，也就是保证有3处备份（为啥要搞这么多备份，下面会专门解释），整理后的照片视频是按月份保存的，方便以后查看。
我的360云盘有43T的空间，目前用了150G了，百度云有3T，空间用的跟360云盘应该很接近。
分为如下几种：
每个人肯定有各种密码需要记住，QQ、微信、邮箱、淘宝、支付宝、12306、银行卡、各种其他需要登录的网站等等，这类密码用chrome浏览器的lastpass插件就全部搞定（刚开始是看到其他同事都在用，也跟着用了，确实很爽），真的只需要记住最后一个密码，那就是lastpass本身的密码，如果对这个插件也不放心，那还可以搞一个文本文件（.txt），把所有的用户名、密码都放进去，然后用压缩软件加密压缩一下，密码设置成你永远不会忘记的那个，当然要比较复杂的，不然可能被暴力破解掉，然后随便丢到哪个云盘里面就好了。
演讲PPT下载：网易私有云IaaS平台介绍
会议网站：http://www.dcdconverged.com/conferences/enterprise-china
官方ReleaseNotes：https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse
nova服务与其他OpenStack服务交互时经过测试建议使用的版本号如下：
官方ReleaseNotes：https://wiki.openstack.org/wiki/ReleaseNotes/Juno/zh-hans
无
官方ReleaseNotes：https://wiki.openstack.org/wiki/ReleaseNotes/Kilo/zh-hans
下面是你在升级中需要了解的内容。在可能的情况下，git提交的hash编码会提供你找到更多更详细的信息：
https://blueprints.launchpad.net/cinder/icehouse https://blueprints.launchpad.net/cinder/juno https://blueprints.launchpad.net/cinder/kilo https://wiki.openstack.org/wiki/ReleaseNotes/Juno#OpenStack_Block_Storage_.28Cinder.29 https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse#OpenStack_Block_Storage_.28Cinder.29
I 版本：
无新功能，增加一些第三方plugin。
J 版本：
DB migration refactor and new timeline
Distributed Virtual Router Support (DVR)
High Availability for the L3 Agent
主要数据库升级方式重构，是DVR以及L3重构。额外有对IPv6的支持，安全组的一些改进。
K 版本：
无新功能，增加一些第三方plugin。
基本没有对我们特别有用的功能，比较多代码重构。数据库升级重构和L3高可用我们已经有了。
