7. Gluster简述

这一节会简述下glusterfs功能和特性。

glusterfs设计符合奥卡姆剃刀原则,即“若无必要,勿增实体”。

cloud-5.2-1

功能特性

gluster集群组成的存储可以通过NFS、CIFS、Glusterfs、HTTP、FTP协议交给用户使用;

GlusterFS_Architecture

gluster支持四种存储逻辑组合:Striped、Replicated、Striped-Replicated、Distributed;

Distributed_Volume

Distributed_Striped_Volume

Distributed_Replicated_Volume

Distributed_Striped_Replicated_Volume

支持跨网备份(geo-replication);

Geo-Rep_LAN

Geo-Rep_WAN

Geo-Rep03_Internet

Geo-Rep04_Cascading

统一对象视图,与UNIX设计哲学类似,所有皆对象;

跨平台兼容性高,可作为hadoop、openstack、ovirt、Amazon EC的后端;

名词解释

砖块(brick):即服务器节点上导出的一个目录,作为glusterfs的最基本单元;

扩展属性(xattr):用户/程序以之将数据和元数据关联起来;

GFID:glusterfs中的每一个文件或者目录都有一个独立的128位GFID,与普通文件系统中的inode类似;

glusterd:运行于所有服务器中的管理守护程序;

6. FUSE

既然是文件系统,那就不得不了解一下FUSE。

FUSE全名Filesystem in Userspace,是在类UNIX系统下的一个机制,可以让普通用户创建修改访问文件系统。功能大体就是连接内核接口与用户控件程序的一座“桥”,目前普遍存在于多个操作系统中,比如Linux、BSD、Solaris、OSX、Android等。

490px-FUSE_structure.svg
图5-1

FUSE来源于AVFS,不同于传统文件系统从磁盘读写数据,FUSE在文件系统或磁盘中有“转换”的角色,本身并不会存储数据。

在Linux系统中的实现有很多,比如即将要用到的glusterfs-fuse。

5. 分布式存储的故事

计算机领域中有诸多有意思的东西可以把玩,在这儿且看看分布式存储。

集群文件系统在某些场景下又可以称作网络文件系统、并行文件系统,在70年代由IBM提出并实现原型。

有几种方法可以实现集群形式,但多数仅仅是节点直连存储而不是将存储之上的文件系统进行合理“分布”。分布式文件系统同时挂载于多个服务器上,并在它们之间共享,可以提供类似于位置无关的数据定位或冗余等特点。并行文件系统是一种集群式的文件系统,它将数据分布于多个节点,其主要目的是提供冗余和提高读写性能。

共享磁盘(Shared-disk)/Storage-area network(SAN)

从应用程序使用的文件级别,到SAN之间的块级别的操作,诸如权限控制和传输,都是发生在客户端节点上。共享磁盘(Shared-disk)文件系统,在并行控制上做了很多工作,以至于其拥有比较一致连贯的文件系统视图,从而避免了多个客户端试图同时访问同一设备时数据断片或丢失的情况发生。其中有种技术叫做围栏(Fencing),就是在某个或某些节点发生断片时,集群自动将这些节点隔离(关机、断网、自恢复),保证其他节点数据访问的正确性。元数据(Metadata)类似目录,可以让所有的机器都能查找使用所有信息,在不同的架构中有不同的保存方式,有的均匀分布于集群,有的存储在中央节点。

实现的方式有SCSI,iSCSI,AoE,FC,Infiniband等,比较著名的产品有Redhat GFS、Sun QFS、Vmware VMFS等。

分布式文件系统

分布式文件系统则不是块级别的共享的形式了,所有加进来的存储(文件系统)都是整个文件系统的一部分,所有数据的传输也是依靠网络来的。

它的设计有这么几个原则:

  • 访问透明   客户端在其上的文件操作与本地文件系统无异
  • 位置透明   其上的文件不代表其存储位置,只要给了全名就能访问
  • 并发透明   所有客户端持有的文件系统的状态在任何时候都是一致的,不会出现A修改了F文件,但是B愣了半天才发现。
  • 失败透明   理解为阻塞操作,不成功不回头。
  • 异构性        文件系统可以在多种硬件以及操作系统下部署使用。
  • 扩展性        随时添加进新的节点,无视其资格新旧。
  • 冗余透明   客户端不需要了解文件存在于多个节点上这一事实。
  • 迁移透明   客户端不需要了解文件根据负载均衡策略迁移的状况。

实现的方式有NFS、CIFS、SMB、NCP等,比较著名的产品有Google GFS、Hadoop HDFS、GlusterFS、Lustre等。

4. 在云端–目录–进度

UPDATE: 2015-05-30 下半部分不如预期中容易,每个算法都要验证并说出所以然,恕小弟不才。

UPDATE: 2015-01-01 上半部分基本完结,下半部分正在添加,在线阅读。如果要成书的话,需要大量添加截图、行动指导以及概念说明。

UPDATE: 2014-06-01 移步http://github.com/lofyer/InTheCloud

UPDATE: 2014-05-30 放入github,以rst格式编写。

UPDATE: 2014-05-15 oVirt章节完成以后整理成word文档,内容更加丰富。

每一章节都可扩展,避免局部发胖,可以从新调整目录结构,比如再加一级父目录和子目录。
硬件部分在搭建的时候可以穿插进来,并不设专门章节讲解。
角度不要起太高,容易扯淡。
不忘资源整合,要有数据。
兼顾智能家居(家庭云)。

第一章 随便说些什么
…1.1 我所看到的
…1.2 今天天气怎样
…1.3 根据需求来架构
第二章 一个可靠的存储后端
…2.1 谈谈分布式存储
…2.2 Glusterfs简述
……功能特性
…2.3 搭建Glusterfs作为基础存储
……添加DNS或者修改hosts文件
……准备磁盘作为砖块
……添加卷
……挂载卷
…2.4 Glusterfs应用示例及技巧
……文件权限
……砖块组合
……normal、replica、striped卷组合
……作为nfs挂载
……作为cifs挂载
……修复裂脑(split-brain)
……砖块复用
……高可用业务IP
第三章 一个合适的虚拟化平台
…3.1 虚拟化平台简介
…3.2 搭建oVirt管理引擎
……系统准备
……添加repo
……搭建普通oVirt虚拟化平台
……搭建管理端高可用oVirt(hosted engine)
…3.3 添加节点以及存储域
……添加节点(宿主机)
……添加存储域
…3.4 连接虚拟机
……Spice-Html5
……浏览器插件
……本地客户端
……spice proxy – gateway – squid代理
……RDP插件(仅适用于Windows虚机及IE浏览器)
…3.5 oVirt使用进阶
……engine-config参数配置
……engine-config参数配置
……ovirt-shell与API
……主机hooks
……主机策略
……虚拟机文件系统扩容
……P2V/V2P
……UI 插件
……使用SysPrep/Cloud-Init重置虚拟机信息
……与其他平台集成、与认证服务器集成
……后端(libvirt/qemu/kernel)优化
第四章 数据抓取与机器学习算法
…4.1 数据收集
……简单抓取
……分布式抓取
……使用Nutch + Solr
…4.2 爬虫示例
……58同城
……知乎
……新浪微博
…4.3 numpy 快查
…4.4 机器学习常用分类算法及Python实现
……信息分类基础
……K邻近算法
……决策树
……朴素贝叶斯
……Logistic回归
……SVM
……AdaBoost
…4.5 无监督学习
…4.6 数据可视化
……数据统计
……地理位置表示
…4.7 机器学习工具
第五章 Hadoop部署及使用
…5.1 Hadoop简介
…5.2 模块部署(单机/集群)
……单节点部署
……集群部署
…5.3 本地数据处理
…5.4 实时数据处理
…5.5 使用进阶
……基于Solr和Nutch的搜索引擎
附录一 OpenStack/Docker/Foreman 以及其他很有用的资源
…OpenStack RDO快速部署
……RDO快速部署
……添加镜像
……从ISO安装新实例
……与owncloud集成
……oVirt使用Glance与Neutron服务
…Docker 使用以及相关集成
……镜像操作
……Registry操作
…Foreman 部署指导
…常用性能测量及优化工具
…SDN学习/mininet
…HAProxy
…常用运维工具
……Ganglia
……zabbix
……nagios
……foreman
……chef
……puppet
附录二 公有云参考
…虚拟机占用主机资源隔离
……网络
……CPU
……磁盘IO
……设备
…资源用度、计费
附录三 PaaS
…这是什么
…当前的形势
附录四 文档参考资源以及建议书单
…Server World
…OVF
…快速安装脚本
…常用爬虫
…Django based WebAdmin
…书单
实践 构建先进的家居云
…系统架构
…构建元素
…OS X Server

3. 要有光

在这里,是整个系统的不同角度视图。

+-------------------------------------+
| +--------------------------------+  |
| | +---------------------------+  |  |
| | | +-----------------------+ |  |  |
| | | |                       | |  |  |
| | | |        appliance      | |  |  |
| | | +-----------------------+ |  |  |
| | |         vm+map_reduce     |  |  |
| | +---------------------------+  |  |
| |          hdfs + hypervisor     |  |
| +--------------------------------+  |          
|               glusterfs             |
+-------------------------------------+
Cluster
|
+--Board
|    |
|    +--Storage
|    |
|    +--Dev_Extension_Board
|
+--Network
|
+--UPS
|    |
|    +--Active/Backup
|
+--Safety
|    |
|    +--TSL
|    |
|    +--Supervision

整个存储是比较倾向gluster作为后端,当然,hdfs是可以使用gluster作为后端的。hdfs的优势之一是可移植性高,可以用廉价的硬件组建(扩展)对性能要求不苛刻的集群。

每一个hypervisor都承载一定数量的计算,当然主要是靠虚拟机内的MapReduce。TBD

Appliance的是使本地计算资源以及互联网资源的融合,作为集群的表现点,拥有识别并体现彼此特征的能力。

2. 畅想吧

单纯人与人的连接关系渐渐已经不能够描述社会这个复杂体了,工业机器也开始走进人的生活,并开始和人互动。Google在2013年一口气收了8家机器人公司,这让我感到…对的,兴奋。

有人说到2020年全球数据总量将达到40ZB,这其中就包含“你幸福吗?”、“你小康了吗?”、“今天中午吃什么?”…你觉得,从数据能判断你的什么?我觉得,该了解的不该了解的,基本都有了。

那我们能拿这些数据做什么呢?

你现在所能看到的,找到的,听到的,都将会是你进行创造的来源,它们为你服务。

我有一只狗,名字叫卡尔,
它能听懂我说话,
帮我发个邮件给阿牛,它会去做。
帮我开台桌面一会儿我要连上去画图,它会去开。
帮我预定曹阳影城的两张门票,它会去订。
帮我找点有意思的新闻,它会整理发送给我。
帮我去给东东和小李送个快递,它也会去送。
帮我买一身衣服,它会买你喜欢的风格。
帮我把找找另外一只拖鞋在哪,它屁颠屁颠的找到了。
……

有很多事情可以帮你甚至代替你去做(原谅我这个robot控)况且,“云”落地总要实体化的。

健壮的身体里,同样要有个健康的灵魂。

1. 众说纷纭

作为公司的一名小小员工,从客户交流到现场部署、从SDN交换机到Neutron、从QEMU到IAAS,我都有过了解或接触,并将其记录成文,是总结,亦是探索。期间难免会有这样或者那样的想法,而将这些想法实践出来的过程是会让人觉得生活依旧是美好的

状况

接下来是以我目前水平能看到的:
和多数行业一样,不管哪个公司,他们技术和关系,在不同客户那里都有不同的权重,这点的南北差异尤为明显;
风(宏观调控)让云去哪,云就去哪;
AppEngine或者OpenShift目前更像是资源(公共数据中心)一厢情愿的产物;

需求

以我所遇到的客户来看,部分客户不会明确的说使用“云”,他们的需求在多数情况下可以有这样或者那样的传统方案替代;
明确要求使用“云”的客户,总会要求周边指标(用户接入、终端协议、视频流占用带宽、UPS、存储复用等)以及各种各样的定制。
所以,在需求上的灵活变通,也是有些许重要性的,不要把技术人员的固执带到客户那

还有什么

TBD

0. 今天天气怎么样?

7:50 手机闹铃响了,随之而来的是你订阅的RSS、Flipboard推送的新闻。随手翻阅下,完后Siri说今天天气挺暖和的,可以穿你最喜欢的高领毛衣,起床。
8:30 高速公路上,地图告诉你前方拥堵,正好这时领导打来电话,你告诉Siri说“接听”。挂了电话以后,红灯亮了,汽车记录下你这次堵车的时间,并默默再次计算预计到时。
9:20 到达公司门口,没有保安,取而代之的是连接公司LDAP服务器的瞳孔识别。
10:00 收到信息,来自楼下快件派发柜,你订购的球鞋到了。
10:30 客户预约的拜访,你告诉Siri说把公司地址导航路线发送给客户张三。
11:10 通过公司IM告诉前台临时允许车牌号为K9031的车辆进来并发送车位信息给客户。
11:20 和客户在临时会客厅谈话,期间你把演说内容通过手势(食指一划)推送到客户邮箱,他们感到很意外(加分点)。

12:30 午餐时间,Siri还记得你在决心减肥期间,提醒你不要吃最喜欢的红烧肉,末了来一句“两个人被老虎追,谁最危险?Bingo,胖的那个”。
14:30 有客户如约送来了10T的财务数据,你通知技术部小李对这些数据进行方案II处理,百分之30的处理任务交给武汉机房的机器,因为这些从机柜到主板都是你依照节能环保的原则主持设计的。
16:00 Siri告诉你,抱歉,六点钟有局部降雨。
17:00 你把今天的备忘录存进公司派发给你的虚拟桌面,下班。
19:00 老婆大人的晚饭做好了,你也再次连上虚拟桌面把备忘录整理归档。
20:30 跑步结束,它告诉你这几周换季期间,要增加运动量,你说“可以”。
23:00 休息,Siri通过文字悄悄告诉你,明天结婚纪念日,记住。

所有已知未知的暗流,让人有了继续折腾下去的欲望。

我是一个着重实践的人,是的,比如磁盘不拆开的话我可能就对扇区、磁道、柱面没什么深刻概念(拆了也就有助于理解驱动,见下图)。所以,这一些列文章将尽量从操作或者现象中总结规律。一些原理性的东西会尽量用我觉得容易理解的形式表现出来。

IMG_20140428_100857

整本“书”的结构将会是这个样子:
介绍下主流“云”的现状,会引用许多现成(尽量)客观的信息片段;畅想一下;从中选择部分组成一个完整系统,进行搭建(或模拟)并本地调优(避免过早优化);避免烂尾,结尾送两首短诗吧。

-1. 为什么我的序号那么奇葩

好的,本文作为未来几十或者上百篇系列文章的第一篇,就不负众望地来个开场白吧:

序号为0的那篇注定作为系列文章(姑且称之为“书”吧)的序言了,但是又不好意思当-0,就-1吧,跟大家随便聊聊。

从07年那会儿,甚至更早,拥有千万用户(包括盗版受害者在内)的行业先锋VMware,又有Google数据中心以及Amazon各种在线服务,这些实打实的东西遵循计算能力的摩尔定律,再顺应日益增长的商业需求,就有了“云”和“大数据”这两个让许多企业再次躁动的概念。

稍微有些行业经验(至少以为是或者看来是)的人觉得这俩只是个噱头;搞大型机的说,嗯,这个,呵呵;搞IDC的觉得一台机器现在当二十台甚至更多卖,不错;搞互联网服务的就有些挠头,咦,这啥?噢,就那玩意儿啊,干嘛起这名?

不管大家都怎么看吧,先引用一句关于“大数据”的经典:

“Big Data is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.”

有时,你我或许都会有迷惘,我这么做(说),对么?

那就这样吧,但行好事,莫问前程

顺便提一下,本“书”对读者的要求是:1.没阅读障碍;2.能提出尽量没有偏见的问题。