windows azure系统简介

Windows Azure Storage

云存储系统，提供给用户：

貌似无限容量的数据存储

貌似可保存任意长的时间

数据按副本存放

本地副本，容忍设备故障

广域副本，容忍地域灾难

强一致性（待看）

 

 

Azure存储系统的元素包括三种：

Blobs（即用户文件s）

Tables（即结构化存储）

Queues（即消息传递）

上述三种数据抽象提供了全部的存储以及工作流，可适用于多种应用

常见的用法：

通过Blob承载进出的数据

通过Queues提供处理Blob的工作流

通过Table和Blob保存中间服务状态和最终结果

 

 

承载的应用

社交网络搜索，视频、音乐、游戏内容服务，医疗记录管理等等

用户可以从因特网登录系统来使用存储

WORM

 

 

内外部用户的需求引导的设计决策

强一致性

         有限制条件的读、写、删除，以提供对强一致性数据的最优并发控制

         能够提供CAP三种属性

                   strongconsistency, high availability, and partition tolerance

全局且可扩展的名字空间

         能够在全世界任何位置进行一致性的数据存储和访问

         EB级以上数据容量

因广域副本而有灾备能力

多租户低成本存储

 

 

全局名字空间

http(s)://AccountName.<service>.core.windows.net/PartitionName/ObjectName

<service> 指定服务类型，可以是blob, table 或 queue

API：http://msdn.microsoft.com/en-us/library/dd179355.aspx

分成三个部分

AccountName：

DNS名称的一部分，AccountName的DNS翻译，用于定位数据所在的数据中心和primary存储集群。

Primary位置是该账户访问该数据的所有请求发往的位置，一个应用可以使用多个AccountName，以便将数据存放在不同位置。

PartitionName：

用于单一请求，定位该请求将到达的存储集群

可用来基于网路状况扩展性地进行数据访问

ObjectName

         当PartitionName对应有多个object时，ObjectName指定具体object

对于在同一PartitionName内的object之间，系统支持原子性的事务

对应于数据抽象：

对于Bolb，其全名是PartitionName

对于Table，table内的每一项（即每一行）有一个主键，其由两部分组成：PartitionName和ObjectName。这样安排可以让应用能够将Table中的行分组，同一分组内可以进行原子性的事务

对于Queue，其名字是PartitionName，在一个Queue中的每个消息具有一个ObjectName用于识别该消息

 

 

Azure存储系统架构

云服务运行在广域多数据中心之上

Windows Azure Fabric Controller是资源分配和管理层，管理资源分配、部署、升级以及云服务的管理

Windows Azure Storage运行在Windows AzureFabric Controller之上

Fabric Controller为Windows AzureStorage提供节点管理、网络配置、状态监控、服务实例的启停、服务部署。

Windows Azure Storage从FabricController获取网络拓扑、集群物理分布、存储节点的硬件配置

Windows Azure Storage负责管理数据和副本的放置，数据和应用流量在存储集群内的负载均衡

Windows Azure Storage的架构组成

         两部分：Storage Stamp和定位服务LS（Location Service）

Storage Stamp构成：

N个机柜（rack）（每个机柜包含多个存储节点（node））组成的一个集群。

每个机柜是一个错误隔离域，有冗余网络和电源。

一个Cluster通常有10到20个机柜，每个机柜18个存储节点（磁盘阵列）

目前单个Storage Stamp容量2PB；下一代的单个容量达30PB

Storage Stamp利用率考虑

         目标是保持70%的容量、处理、带宽的利用率

         避免超过80%，原因：

（1）减少寻道开销、尽量利用外磁道来获得更好的响应和吞吐量

（2）当一个机柜故障时，保持Stamp的可用性

当一个存储Stamp达到70%时，定位服务通过跨stamp的副本将账户迁移到其他的stamp。

定位服务Location Service

管理所有的Storage Stamp

管理涵盖全部Stamp的账户名字空间

管理账户定位到哪个Stamp，以提供容灾和负载均衡

自身在两地部署，容灾

Windows Azure Storage分为亚美欧三个地域，每个地域有多个地点，每个地点一个数据中心，每个中心放置在一到多个Building，每个地点有多个storagestamp

LS能灵活增加地域à地点àstamp

LS负责将账户导向给新加入的stamp

LS负责负载均衡

LS的运作机制：

         应用申请一个新账户（指定了地点）àLS在该地点选取一个stamp（根据综合负载选择）àLS将此账户信息存放至此stamp（这就告诉了此stamp可以接收该账户的请求）àLS更新DNS，将请求导向该stamp的VIP（Virtual IP）。

 

Storage Stamp的三层结构

Stream Layer：

相当于文件系统，负责文件存放在单个Stamp中，负责完成存放和复制，但不知道高层的object组织及其语义。

【从这个角度来看，用大文件集合小文件，利用副本或BWRAID技术维护可靠性，是有必要的。可以减少元数据负载，发挥蓝鲸优势，利于元数据保护。】

数据在Stream Layer存放，但可从PartitionLayer访问，每个node中都有这两层。

Partition Layer：

管理高层数据抽象（Blob，Table，Queue）

提供可扩展的object名字空间

提供事务排序及object的强一致性

在Stream Layer上存放object数据

缓存object数据，提高性能

         提供在单个stamp内的所有object的partitioning以获取高扩展性

每个object都有一个PartitionName，决定在那个partition server，本层管理partitionserver服务“哪些PartitionName范围”的Blob、Table和Queue

负责在partition server之间进行PartitionName的负载均衡

Front-End Layer：

一组无状态的服务器，接收到来的请求

验证权限à通过PartitionName路由请求至partitionlayer的具体server

可缓存Partition路由信息，对于大的对象，可以短路至stream层

 

两级副本引擎

         Stamp内副本引擎（位于stream layer）

同步复制，在关键路径上（全部replica都成功后才返回）

副本分布在不同错误隔离域的不同node

disk、node、rack级容错(关注于硬件损坏)

         Stamp间副本引擎（位于partition layer）

异步复制，不在关键路径上（关注于不可抗拒的灾难）

复制整个对象，或对象的增量修改

目标两类（1）不同地点，用于容灾（2）在stamps迁移账户数据

Stamp间副本关注对象和对象上操作的复制，Stamp内副本关于于block块级别的复制

Stamp内副本由于范围小，元信息得以全部维护在内存中，提高速度

Stamp间副本有LS，有全局名字空间，便于跨数据中心的object复制

 

 

Steam Layer文件系统

只提供给partition layer使用，是write-append-only型文件系统

Steam即文件，由一组有序的extent指针构成，extent即一组【物理和逻辑上都是？】顺序的block

Block

是数据读写的最小单位，相当于文件系统的Block

Block不一定是固定大小

Block末尾加有checksum及时监测数据错误，读取每块时均检查

Extent

是副本的基本单位，每个Extent是一个NTFS文件

多个小的Object可存放在同一extent甚至同一block中

Partition layter记录Object对应的stream、extent、byteoffset位置

Stream

每个Stream在stream layer维护有名字

连接两个Stream是常见操作（即更新extent指针）

除最后一个extent可追加外，其余extent不可变

 

Stream Layter两大组件：Stream Manager和Extent Node

SM是标准的Paxos cluster

SM管理stream名字空间、extent的分配等，相当于BWFS的MS，也是带外方式

除MS功能之外，SM完成：

硬件失效后的副本重构，重构副本随机选择不同的错误隔离域

根据stream策略，控制extent数据的erasure编码

SM只关心stream和extent，不涉及任何block信息（量太大）

EN

EN管理extent和block的对应，block有Checksum

Extent相当于文件

EN负责extent的数据复制，EN对每个extent记录有副本位置

 

Extent的写追加和断界

追加操作只具有block原子性，

不追加、1整个block追加、多个block一次追加

客户端（即partition layer）对于“多个block一次追加”要么成功，要么失败重试，要么将该extent断界

这意味着服务端应该正确处理重传的一次性语义，包括复制副本的情况

元数据stream和commitlog stream有顺序号，相应副本操作的顺序号与之一致

Row data stream和blob data stream，当重写时，仅最后的写会记录到RangePartition中，未成功写被垃圾回收

Extent有客户端（即partition layer）指定的目标大小，在该大小的block边界上断界

断界后的Extent不可变

stream layer可对断界后的Extent进行优化，例如对冷extent进行erasure编码

Extent可大小不一，可任意时刻断界

 

 

Stream Layer的Stamp内副本

Stream Layer和partition Layer协同设计提供object事务的强一致性，基于

追加操作完成并返回确认后的任何读是相同数据

Extent断界后，任何断界后的extent副本内容相同

Stream副本不考虑上层恶意行为

仅考虑造成数据损坏的错误

用checksum来探测此类错误

 

创建Stream时，SM负责分配3个extent到不同的EN上（并考虑到EN的负载均衡）

Extent元信息维护和使用方式和BWFS类似

3个extent一主两副，客户端写主，EN间交互写副

客户端只写主，但可读副

主extent在写期间（即unseal）位置固定

可保障append顺序唯一

保障数据一致性？？

 

主EN负责管理

确定该extent数据追加的offset

并发的多个追加请求的排序

将确定的offset发给两个副EN

只有在3个extent都追加成功后才对应用返回success

多个请求的success回复按照offset的顺序返回

最后Commit的位置称为该副本的commit length，commit也按顺序

 

当遇到错误时，seal该extent

客户端缓存extent的metadata，直接访问EN

出错时，EN通知SM

SM将该extent seal，然后分配新的extent给客户端（平均20ms以内）

关键是不等待EN重新可用

         Seal的extent，在后台维护需要的冗余度

 

Seal extent时

选取可达的该extent对应的所有EN

选最小的commit length对extent进行seal

当未可达EN可达后，强制为该length

一致性由主EN的success返回机制来保证

 

和Partition Layer的交互

当network partitioning，客户端（partition layer）可与EN交互，但SM不能与该EN交互时

partition layer有两种读模式

（1）对于row和blob类型的stream，可读已经成功返回过的位置

（2）对于metadata和commit log类型的stream，

在partition加载时，需要从头读到尾

partition layer保证在partition加载时不做任何追加

partition加载时，partitionserver对这两类stream的主EN发送check commit length请求，如果不一致，extent会被seal（按照SM曾seal过的副本）。

 

已Seal的extent的erasure coding保护

将3副本变成1.3-1.5，每个extent按block边界分块，然后再加入纠删块【估计不是这样做的】erasurecoding保护比3副本可靠性有提升

 

读的负载均衡

读附带有一个deadline时间，如果EN不能满足，马上通知客户端换EN。如果都不能满足，还可通过读取足够的erasure code块来重构出数据。

 

磁头防拥塞调度算法

兼顾性能和读写公平性，对某些顺序请求性能有折中

 

日志

即使在Append-only的系统中，日志卷的使用也有明显的好处。

用整个磁盘或者SSD来做日志卷

平均追加延迟从30ms降到6ms

 

 

Partition Layer

为不同的对象提供相应的数据模型

处理具体类型对象的逻辑和语义

对象的高扩展名字空间

在partition server间对象访问负载的均衡

对象访问的事务排序和强一致性维护

 

Partition Layer数据模型

重要内部数据结构：Object Table（OT）

OT即大表，可增长至PB级

OT动态划分为各个RangePartition，分布到一个Stamp的各个Partition Server中

RangePartition是OT的连续几行，RangePartition彼此不重叠

每一行都属于某个RangePartition

 

Partition Layer使用的各种OT

Account Table，存放该stamp的存储账户的元数据和配置信息

Blob Table，存放该stamp内所有账户的所有blob对象

Entity Table，存放该stamp内所有账户的所有entity行

Message Table，存放该stamp内所有账户的消息队列上的所有消息

Schema Table，存放所有OT的schema，每个OT有其固定的schema

Partition Map Table，存放所有OT的当前的RangePartitions，以及每个RP当前服务的partition server【该表用于前端服务器进行请求路由】

BT、ET、MT的主键包括3个部分：AccountName、PartitionName、ObjectName，用于索引和排序

 

OT schema支持的类型

基础类型（bool、binary、string、DateTime、double、GUID、int32、int64）

特殊类型DictionaryType、BlobType

DictionaryType用于某行随时加入不固定类型的属性（无固定schema）

（名字、类型、值）三元组

行为无区别，可像其他属性一样查询

BlobType现仅用于BT

其中不存放blob的数据信息

blob的数据信息是一组“extent、offset、length”指针，存放在单独的blob data stream中

BlobType存放的是一个指向“blob的数据信息”的指针

OT支持的操作

标准的增、改、删、查、取操作

批处理事务操作

拥有相同PartitionName值的多个行的批量事务

一个批量事务按单个事务进行处理

OT支持快照从而允许读写同时进行

 

Partition Layer的系统结构

Partition Manager

将大的OT划分为不重叠的RangePartition

记录RP当前由哪个Partition Server提供服务

保障RP在任一时刻仅有唯一的PS提供服务

提供RP对于PS的负载均衡

单个stamp中有多个PM实例

通过Lock Service来确定PM中唯一的leader，leader负责控制整个partition layer

Partition Server

负责提供PM分配给该PS的RangePartitions的服务

将持久状态信息记录在stream中

通过Lock Service保证一个RangePartition不会同时被两个PS服务【以此提供事务的顺序性和数据的强一致性】

当前系统一个PS平均服务10个RangePartition

Lock Service

Paxos Lock Service用于PM的leader的竞选

保证一个RangePartition不会同时被两个PS服务

PS失效时

PM负责其上的RangePartition分配到其他PS

并更新Partition Map Table，供前端路由使用

 

RangePartition数据结构

一组内存结构

一组放在stream的非易失数据结构

 

RangePartition的非易失数据

用LSM维护

【OT的每个RangePartition包含多个stream，每个steam只属于一个RangePartition；但Split时可能属于不同RangePartition的多个stream会引用相同的extent】

Metadata Stream

RangePartition的根stream

PM用该stream的名字和PS交互

包含加载该RangePartition的足够信息

还包括尚未完成的split和merge操作信息

Commit Log Stream，记录该RP上一次checkpoint以来的增删改操作

Row Data Stream，存放该RP的checkpoint的row数据和索引

Blob Data Stream，仅BT用于存放blob data bits【即一组“extent、offset、length”指针】

除BT外，每个RP只有1个data stream

BT有1个row data stream和1个blob data stream

 

RangePartition的内存结构

Memory Table，commit log的内存版本，存放未checkpoint的所有最近的更新

Index Cache，存放row datastream的checkpoint索引，和Row Data Cache分开的目的是尽可能的将主索引缓存在内存中

Row Data Cache，checkpoint rowdata的内存只读cache，查找时用

Bloom Filter，如果数据在memorytable和row data cache中都没有找到，那么就要在data stream中查找索引和checkpoint。用于加速确定要访问的行是否可能在待查找的checkpoint中

 

Partition Layer的数据流

 

PS接收到一个写请求（例如增、删、改）à将请求追加到commit logà将新改的行放到memorytable中à向FE server返回成功à当memory table或commit log达到大小阈值，PS将MT中的内容写到一个checkpoint，存放在该RangePartition的row data stream中à移除相应的commit logà（周期合并小checkpoint为大checkpoint，控制checkpoint数量）

 

若是BTàBlob data bits也存放到commit log（但不放到memorytable）àcheckpoint时，extent直接链到RP的Blob data stream中（不用移动数据，开销极低）

 

PS加载RangePartitionà读取meatadatastream，确定活跃checkpoint位置à重放commit log重建内存状态à提供该RangePartition服务

 

RangePartition的负载均衡

负载均衡是Partition Layer的关键部分

将OT分为RPs，根据负载需求变化在各个PS间均衡分配RP

在一个stamp中，PM具体执行RP的Balance、Split、Merge三种操作

 

 

Partition Layer的Inter-Stamp副本机制

一个AccountName有一个主stamp，一个到多个副stamp（通过LS分配）

Asure将该AccountName的主stamp数据向副stamp复制

 

 

 

 

6.应用吞吐量分析

对于某个account的某个大小为100GB的table执行put 和 get 操作。

横轴代表VM（虚拟机？）的数量，可以理解为外部应用请求的数量

纵轴代表每秒处理entities的数量。

 

下图展示了get 或者 put 4MB的blob时候，随着VM数量增长，系统的吞吐量。

 

 

从上面两张图可以看出：

1.      对于entities的访问，是可以实现线性增长的；对于blob，当VM数量超过8以后，由于网络带宽成为瓶颈，无法实现线性增长。

2.      对于TABLE操作，batch put 操作的吞吐量大概是单个put操作的3倍，这是由于前者显著地降低了网络开销减少了streamwrite的操作。

3.      Table read操作的吞吐量比Table write 操作的吞吐量略微低一些。这种差异是由于我们实验的特殊访问模式造成的：随机访问一个较大data set 的较大key space，会最小化cache的作用，而write操作总会以顺序的方式完成。

 

 

 

7.负载简介

1>  不同的customer具有明显不同的使用模式

2>  在capacity usage方面，Zune和Xbox Gameserver 大多数是非结构化数据，其他多以结构化数据为主

3>  Queues 使用了非常少的空间，这是因为其只被用作通信机制而不是长久的数据保存。

 

 

 

8.设计选择和所学的知识

 

1>    计算与存储的分离

可以分别扩展计算核心与存储容量

并且可以在计算和存储直接设置一个单独的层次，提供multi-tenancy的用途

允许不同层次上单独进行负载均衡的调整。

 

为了实现以上目标，一个关键的前提是：

计算单元可以有效的访问存储资源，需要防止被访问的数据处于同一个node，甚至同一个rack

这样的网络架构正在被研究。

 

2>    Range partitions 与哈希的选择

选择range partitions的原因：

1. 某个给定account的所有object 是存储在同一个range partitions,这样有利于隔离操作以及有效的枚举所有object
2. 使用哈希虽然可以比较容易在多个server间实现简单的负载分散，但是不具有object的聚集特性。
3. 使用range partition ，WAS把某个customer的所有object 置于他们自己的set of partition之中，这样可以防止和隔离潜在的abusive accounts。

3>    Throttling/isolation (禁止与隔离)

当servers的负载过重，识别出哪个storageaccount 应该被禁止以保证正常account的访问不受影响，这是个困难的问题。

系统使用sample-hold 算法，记录请求速率最高的N个AccountName 和PartitionsName.

一旦某个server 发生overload的情况，使用上述信息选择一个accounts来throttle。

一般来说，负载均衡模块会尽力维持系统的正常运转，但是当access patterns不能被load balanced，则系统会throttle某个request。

 

 

4>    主动的负载均衡调整

为了使WAS在各种环境下保证高可用，我们的工作主要致力于以下几个方面：

1. 收集adaptive profile 信息，2.发现那个种度量标准在多种traffic条件下最有效3.调整算法使之能够聪明能够有效处理不同的traffic pattern.

根据某些指标来确定某些partition是否达到容量的上限，是否需要splitting

这些指标包括

Request  throttling      请求超时         partition 的容量过大

具体操作

PM每隔15秒就按照一定顺序（splitting 紧迫程度的降序）检验每隔server，看是否需要splitting，若需要就选择一个负载较轻的进行操作。

 

核心的负载均衡算法可以动态的替换。WAS支持定制特定的负载均衡逻辑，比如设计基于不同的系统测量的partition splitting 触发器。

 

5>    每个rangepartition具有单独的log files

这种设计是我们可以或者获知每个rangpatition 的访问情况，以实现performanceisolation的目的。

 

6>    日志

起初系统中没有日志，这使得在同一个drive上由于读写竞争，出现了许多hiccups（短暂的停顿，暂时的小问题）。

在每个rangepartition上加入日志之后，非常有效的降低了时延，提供了consistent performance。

 

 

 

7>    Append-only system

简化了副本协议和错误处理，并且增强了一致性。

可以没有任何额外代价的保存系统之前的快照

可以高效的优化系统，例如增加纠删码

非常有利于系统诊断和错误恢复

 

Appendonly 也带来了很多开销

高效和可扩展的garbage collection 来了额外的I/O.

另外，磁盘上的数据布局可能与virtual address space of the data abstraction 不一致，这要求我们为streaming large data sets实现预取。

 

 

8>    端到端的checksums

数据从用户发出，途径 front-end server partition server stream server 都会计算 checksum，以保证数据完整性。

若出现错误，则向上层返回。

 

9>    upgrades（升级）

一个 upgrade domain 是orthogonal tofault domain.

如果只某个service upgrade ，那么所有服务器中至多只有1/y的数量处于upgrade的专状态（不可以状态），其中Y是upgrade domain 的数量。

使用rolling upgrade的策略，每次只操作一个server。

在关掉某个upgrade domain之前，都要通知PM，防止在其上分配新的extent。

并且要确认会有足够多的副本在升级期间是可用的。

 

 

10> 在同一个stack上实现多种数据抽象

Blob  Table queues使用同样的intra-stamp 和inter-stamp 副本，

使用同样的负载系统，将不同的访问者的负载混合在共享资源上，把三种不同的数据抽象存储于相同的存储节点集合中

 

11>  使用系统预设定的objecttables

选择使用固定数量的系统定义的object table，来构成Blobtable  queue de ,而不允许用户随意扩展。

这减少了管理开销，是内部的数据结构简单可控。

 

 

12> Offering storage in buckets of100TBs

限制每个account 的最大存储容量为100TB，这个限制允许所有storage account data适合于某个给定的stamp

为了获取更多的存储空间，数据只能分成多个account来存放。

 

13> CAP原理

在一个storage stamp 内部，满足CAP三个特性，这归功于分层和特殊容错模型。

Append-only 数据模型面对网络分割或者其他failure时候，可以提供高可用，

建立与stream layer之上的Partitionlayer 提供了强一致性保证。

这种分层，使得负责可用性和负责一致性的节点在面对网络分割时候互不干扰。

例如 当node  failures 和 top-of-rack failure发生后，stream 层会停止使用这个rack，将数据写到其他可用的rack；同时，partition层会把rangepartition重新分配的其他的基于可用rack 的PS上。

 

14> High-performance Debug logging

在开发WAS的过程中，使用了debug logging，记录在存储节点的本地磁盘上，并且提供在所有节点的log中的分布式搜索。

在WAS的产品化时候，出于性能考虑释减少了log的数量。

 

15> Pressure point testing

在一个规模较大的分布式系统中，为所有复杂操作的所有组合设计测试用例是不现实的。

系统提供了一些编程接口，以实现主要的操作，以及可以create faults 的point

Pressure point 系统使用这些接口来触发需要测试的操作。

 

 

相关工作

1. 在一个不是非常稳定的网络下，分布式系统所面临的可用性和一致性的考验。
2. 一些系统被迫采用最终一致性的解决方，如Amazon的Simple DB。

3．WAS使用异地副本的异步实现，从而避开了关键路径的延迟。

 

和WAS最为接近的是GFS，但是区别如下

1.GFS         是基于松散的副本一致性模型，不能保证所有副本是bitwise相同的，而WAS是可以的

2.GFS的BIGTALBE 是所有表格的操作记录到一个log中然后记录的文件系统中，而WAS是分别记录，并且是在stream layer 完成。

3.WAS提供了一个可扩展的Blob存储系统，并把Table transaction集成到一个类似于BIGTALBE的框架中。