832-269-3317

重拾之前填的坑,深入解析系列。声明:本文不涉及任何微软内部资料,大家可以放心传播和阅览。 :)

之前把存储解析说了个7788,剩下的部分有些太内部+太枯燥,细细想来还是就此打住为妙,也为以后为客户讲课留个缺口 🙂

今天开始重开另一个坑,Azure平台架构之Fabric Controller。 这个是Azure平台最核心最底层最面向数据中心也是和超大规模云计算架构最有关联的一部分。有兴趣了解Azure和有兴趣学习大规模云计算平台架构的同学都值得一读。

其实Azure本身的发展也是经过了相当长的一段时间的,其中核心模块诸如Fabric controller, storage等等的架构也是发生过一定的变化的。不过变化的通常是核心模块里的一些小组件,对于整体的功能和工作原理,并没有伤筋动骨意义上的变动。这里说一句题外话,随着ARM(azure 资源管理器)模式的引入,我之后的架构和应用博文会更多的介绍ARM相关,也希望大家使用Azure的时候也都尝试应用一下,毕竟这是下一代的管理模式,也更方便客户体验Azure。

言归正传,什么是FC(fabric controller)? 要介绍FC前就一定要先说一下Azure平台的架构。

图1:

如图所示,Azure数据中心就是一个庞大的分布式的集合。由多层路由,负载均衡器和物理节点服务器构成。其设计的主要原则就是保证每个从主路由来的request都可以到达数据中心内的任何一个物理racks。也抱着每个switch和racks都有冗余,没有单点存在。

在Azure的架构里,其实一个region的数据中心是会被分为几个不同的cluster,其中会有将近1000多台物理的服务器,我们称之为node。每个逻辑的cluster单位,都会有个一个fc来管理,fc会负责处理:

  • Blade provisioning
  • Blade management
  • Service deployment and lifecycle

简而言之,fc会管理硬件服务器的部署和使用,是真正完成服务部署和管理生命周期的组件。

这里有个比较有趣的比喻。其实fc就相当于Azure这个云操作系统的kernel,我们的数据中心就是这个系统所依赖的硬件,而我们的服务就是这个kernal所调动的进程。

那在整个FC的管理体系里,还有一个UFC,相当于我们FC的leader。他会负责起动别的fc,并把服务器node的信息用XML的形式传递给fc,方便fc管理资源。举个例子,在很多cluster技术上,比如etcd等,都会使用选举leader的做法,这里我们用的就是先制定一个leader来传递服务器配置信息,然后让fc去管理对应的服务器,当然,这里没有选举的算法存在,原因我们后面再说。以前UFC是作为单点在数据中心中的,后来我们意识到单点故障的可能性后Fix了这个隐患。

那FC在cluster里是如何存在的呢?请看下图。

图2:

fc是作为一个分布式,有状态的应用跑在服务器上的(当然,是分布在不同的FD中保证高可用性)。每一个服务服务器里的第一个blade server上,跑的就是咱们的fc。一般来说,node 1 会是uufc,node2 是active ufc, node3是standby ufc。 剩下的就会是fc, slb fc,standby fc。基本上,同时工作的只有5台FC,剩下的都是我们的standby fc。这样可以充分保障整个数据中心工作的高可用性,因为整个数据中心的kernel永远都处在信息一致并且有多个备份的情况下。

在数据中心里,一个node的启动过程是这样的。

图3:

  • 启动一个node
  • Pxe 我们的maintenance os->相当于我们家用的win pe
  • Host agent 会格式化磁盘然后通过WDS来部署这个定制化OS
  • 启动,sysprep,reboot
  • fc就可以通过os里内置的host agent来和node通信了

Windows Azure 内部,通常都是使用agent和我们定制的通信协议来完成host to guest的通信的。这样一方面是解决消费者问题,另一方面也是加强了定制化能力和拓展能力。

说完了‘硬’概念,我们来看看‘软’概念。大家都知道,sdx = 软件定义一切目前是潮流。软件定义的存储,数据中心,网络已经使得大部分的云提供商甚至大型互联网公司都具备了使用自定义服务器甚至白盒的能力,不必被以前的所谓IOE绑架,这也是传统厂商在云时代不被看好的原因。

那在azure上,SDX的精神是怎么样发展的呢?其实如我之前所说,整个azure平台已经是完全、完整、完备的一整套软件定义数据中心了。(这也是为什么我们可以把azure stack掏出来作为私有云方案)。之后我会通过介绍部署服务的生命周期也印证fc作为kernel的能力和azure软件定义数据中心的成果。

当我们在portal上或者visual studio里部署方案的时候,其实相当于提交了一份符合azure schema的cloud defination file给Azure前段。这里引出了另外一个组件叫rdfe-> red dog front end亦就是处理我们cloud service request的组件。这个组件我们在FC系列里不会细谈,它其实就是一个parser来处理我们的csdef/cscfg问题,把它转换成我们fc可读的 .svd格式即Azure内部container/instance启动环境配置文件。

有了这份环境配置文件(instance container configuration file), 我们的fc就有了处理这个service request的动力。整个service deployment 的步骤是复杂的,其中牵涉了很多内部的组件和各个resource provider。这里我提供一个大概的流程:

  • 解析资源的需求,创建/调用对应的image
  • 申请对应的compute/network/storage 资源,preallocate
  • 根据权重算法,挑选最合适的node
  • 先创建存储资源,建立好VHD,再挑选网络资源完成分配,最后创建VM,配置SLB允许外部traffic

其中,我们会通过几个小组件(allocator, node/container/network manager)来控制整个资源选择和分配。至此,一个VM或者web role/worker role就诞生了。

图4:

我们可以清楚的了解到,fc会通过host agent来管理一个物理node的资源分配和instance update。通过image repo和agent,我们可以创建vhd然后通过host agent和guest agent的通信来格式化和配置一个VM。这也就是我们的guest agent/rdagent在整个部署中起到的作用。

顺便解答几个大家在使用Azure上容易产生的疑问。

1.为什么我的机器最多只能升到A7,而不能升到D系列?

答:这就是因为role instance绑定在了只支持A7系列的物理cluster上。试想一下,如果一个cluster里的物理服务器全是共享或者相对老一些的硬件,那他们是否能够提供D-F-G系列的计算能力?答案肯定是否定的。那如何改变或者避免这种情况?

可以选择下面几种方案:

  • 删除cloud service, 保存vhd再重新建立新尺寸的虚拟机。前提是不要在temp driver上保留文件,这样会导致数据丢失。
  • 在创建时就选择D或者高系列的vm,这样可以保证虚机所在的所创建的VHD是停留在比较新的物理服务器上。
  • 选择用resource manager模式部署,这个是跨region的避免物理限制的方法,以后我们详细介绍一下。

2.我可以选择我的后端服务器使用哪种CPU或者选择最新一代的硬件吗?

答:如果单纯部署,靠FC算法选择资源的话,是不行的。因为会根据权重的服务器性能随机分配。但你可以用上面的办法,达成一样的效果。

3.为什么要选择UD/FD?在数据中心,他们是怎样的?

答:在我们的数据中心中,一个rack就相当于一个FD,fault domain。他配备了一个tor,一个pdu。这样可以保证在一个Cloud service有2个以上instance并在2个rack上,保证高可用性。UD是逻辑概念,保证不会同时upgrade。

第一部分就先到这里,下次我们再来谈谈一些更细节和更切合实际应用的topic。也欢迎大家提问。

Azure架构解析-存储1

这个标题牛逼不?其实还可以用诸如,21天速通微软云,深入浅出微软云,我和微软云二三事等标题形容本文,然而本着技术为主,休闲为辅的原则,踏踏实实的用架构解析来标题,也算我软一贯踏实技术,不管市场的作风。


进来一直在看Azure底层的东西,看多了自然感悟也多,分享一些心得体会和设计原理,也算对得起咱的抬头~


免责事项:本文不牵涉任何机密信息,全都是网上可以搜到的,自由转发。


——————————————————————————————————


说道云平台的架构,最容易去学和看的,无非就是openstack了。 其实做到够大够全够稳定,基本的原理都是差不多的。遵从cat原则,Lamport的2个算法(paxos,面包店)。算法和原则相对简单,但工程上的实现就可以算是艺术了。大家如果有兴趣,可以去看openstack的相关代码,一定受益匪浅。


说回Azure, Azure本体可以分为6个模块(简直可以说是六脉神剑), Azure fabric controller(azure kernel), Azure OS(节点系统),Azure runtime(插件和通信), Azure net(azure网络模块),Azure Storage以及RDFE(red dog front end)。 各模块各司其职,每个模块本身已经非常强大,组合在一起,更是威力无穷。今天承接上一篇存储相关,咋们先讨论Azure storage。




  1. 存储系统是Azure开发初期很早实现的一个模块和功能,也是初期PAAS时期一个非常重要的组成部分。好的平台诸如aws,aliyun,ucloud等,对于云存储的开发和维护都是很重视。大家时不时可以看到各种存储的评测和性能分析便可见一斑。 Azure storage是遵从一个名为global partitioned namespace的原则设计的,目的就是能提供诸如#存储一致性, #全局扩展, #灾难恢复,#共享存储的特性。我们先从高层架构开始说起。



Azure架构解析-存储1


从物理机来说,存储系统的节点称为storage stamp。它是由N个rack组成的物理cluster。每一个rack都是独立的fault domain,由不同的供电设备和网络加持。过去的一代节点是由10到20个包含18块硬盘的rack组成。现在的物理节点已经有超过30PB的存储量。每个物理节点的使用率一般都不会超过70%,这是为了提高seek time和加强磁盘性能。一旦超过70%的使用率,存储系统里的位置服务会把新加入的storage account迁移到别的存储节点。稍后会有介绍。


    2. storage stamp的三层抽象层。如图所示,大家应该都对于这3个front-end, partition layer和stream layer有疑问,他们各是干什么的?


Stream layer如图可见是最下面的一层也是最接近硬件的一层,它是用来存储真正的数据,并且负责分发和复制数据的一层。它也是真正意义上的分布式存储系统的一层。它会将数据数据分成extents,并称chunks,然后以stream的方式去存储和复制他们。它不参与上层的对象等逻辑管理,踏踏实实的管理block/entents level的数据。


Partition layer.这一层是用来管理逻辑(或者说抽象)数据的。大家都知道,azure上是分blob, table,queue的数据类型的。而去真正操作他们的或者说作为中间层服务的就是这层。存储系统会自动进行一些类似分区的操作,其好处不言而喻,而负责管理分区和查询也是partition layer的职责所在。它会指示partition server去为相对应的数据类型服务,还有load balancing和traffic direction的功能。


Frontend layer. 它是一个stateless的前端服务,主要去接受来自compute之类的incoming request。一旦受到一个io 请求,FE会帮忙去查找account name, auth信息,以及导向partition server。Fe 本身维护了一张map表来查找对应的partition name 和server。如果blob太大,fe还能自动写入stream层,避免查找partition 和分发的overhead.


今天就先说到这里,下期我们聊聊replication engineer和每一层具体的设计原理和细则。



始发于微信公众号: IT小圈子

7314252934

这个标题牛逼不?其实还可以用诸如,21天速通微软云,深入浅出微软云,我和微软云二三事等标题形容本文,然而本着技术为主,休闲为辅的原则,踏踏实实的用架构解析来标题,也算我软一贯踏实技术,不管市场的作风。

 

进来一直在看Azure底层的东西,看多了自然感悟也多,分享一些心得体会和设计原理,也算对得起咱的抬头~

 

免责事项:本文不牵涉任何机密信息,全都是网上可以搜到的,自由转发。

 

——————————————————————————————————

 

说道云平台的架构,最容易去学和看的,无非就是openstack了。 其实做到够大够全够稳定,基本的原理都是差不多的。遵从cat原则,Lamport的2个算法(paxos,面包店)。算法和原则相对简单,但工程上的实现就可以算是艺术了。大家如果有兴趣,可以去看openstack的相关代码,一定受益匪浅。

 

说回Azure, Azure本体可以分为6个模块(简直可以说是六脉神剑), Azure fabric controller(azure kernel), Azure OS(节点系统),Azure runtime(插件和通信), Azure net(azure网络模块),Azure Storage以及RDFE(red dog front end)。 各模块各司其职,每个模块本身已经非常强大,组合在一起,更是威力无穷。今天承接上一篇存储相关,咋们先讨论Azure storage。

 

 

 

  1. 存储系统是Azure开发初期很早实现的一个模块和功能,也是初期PAAS时期一个非常重要的组成部分。好的平台诸如aws,aliyun,ucloud等,对于云存储的开发和维护都是很重视。大家时不时可以看到各种存储的评测和性能分析便可见一斑。 Azure storage是遵从一个名为global partitioned namespace的原则设计的,目的就是能提供诸如#存储一致性, #全局扩展, #灾难恢复,#共享存储的特性。我们先从高层架构开始说起。

 

 

Azure架构解析-存储1

 

从物理机来说,存储系统的节点称为storage stamp。它是由N个rack组成的物理cluster。每一个rack都是独立的fault domain,由不同的供电设备和网络加持。过去的一代节点是由10到20个包含18块硬盘的rack组成。现在的物理节点已经有超过30PB的存储量。每个物理节点的使用率一般都不会超过70%,这是为了提高seek time和加强磁盘性能。一旦超过70%的使用率,存储系统里的位置服务会把新加入的storage account迁移到别的存储节点。稍后会有介绍。

 

2. storage stamp的三层抽象层。如图所示,大家应该都对于这3个front-end, partition layer和stream layer有疑问,他们各是干什么的?

 

Stream layer如图可见是最下面的一层也是最接近硬件的一层,它是用来存储真正的数据,并且负责分发和复制数据的一层。它也是真正意义上的分布式存储系统的一层。它会将数据数据分成extents,并称chunks,然后以stream的方式去存储和复制他们。它不参与上层的对象等逻辑管理,踏踏实实的管理block/entents level的数据。

 

Partition layer.这一层是用来管理逻辑(或者说抽象)数据的。大家都知道,azure上是分blob, table,queue的数据类型的。而去真正操作他们的或者说作为中间层服务的就是这层。存储系统会自动进行一些类似分区的操作,其好处不言而喻,而负责管理分区和查询也是partition layer的职责所在。它会指示partition server去为相对应的数据类型服务,还有load balancing和traffic direction的功能。

 

Frontend layer. 它是一个stateless的前端服务,主要去接受来自compute之类的incoming request。一旦受到一个io 请求,FE会帮忙去查找account name, auth信息,以及导向partition server。Fe 本身维护了一张map表来查找对应的partition name 和server。如果blob太大,fe还能自动写入stream层,避免查找partition 和分发的overhead.

 

今天就先说到这里,下期我们聊聊replication engineer和每一层具体的设计原理和细则。

 

 

始发于微信公众号: IT小圈子

724-364-7410

 


如何enable AzureLinuxVM Swap空间



督促自己记录和分享,来一发~


如何enable AzureLinuxVM Swap空间


很多用户在使用Azure Linux VM的时候都有一个问题, 为什么Azure不自动提供swap分区?其实这个在很多云主机上都有相同的疑问,这个牵涉到了云主机和本后数据读取的算法结构问题。关于具体enable后性能的差异,等我有空了来分析一下~


先讨论如何enable这个swap空间。一般我们会用fallocate chmod 600 mkswap swapon来enable它,当然还要在fstab里添加记录。但这里我们介绍另一个方法和思路。Azure的temp drive是ssd,性能不错,而且不收费,大家要注意利用哦~(D series).


如何enable AzureLinuxVM Swap空间


首先一样,putty ssh进自己的VM。这里还是以CENTOS 7.0作为演示

如何enable AzureLinuxVM Swap空间

可以看到,一开始确实没有swap空间。


然后我们进入waagent来配置swap空间,这里的linux waagent非常有用,以后有时间会做个waagent åŠŸèƒ½è§£æžã€‚


如何enable AzureLinuxVM Swap空间


定位到/etc/waagent.conf,修改 ResourceDisk.Format -> 'y'
修改 ResourceDisk.EnableSwap -> 'y'

修改swapsizeMB到你喜欢的数字,笔者喜欢1024~



如何enable AzureLinuxVM Swap空间

保存然后sudo service waagent restart.


稍等片刻———–>



如何enable AzureLinuxVM Swap空间

搞定->重启依旧有效


那究竟是怎么做到的呢? æˆ‘们来看一下代码

(waagent是python写的,源代码在github上,大家都可以看)

        #Create swap space         swap = Config.get("ResourceDisk.EnableSwap")         if swap == None or swap.lower().startswith("n"):             return         sizeKB = int(Config.get("ResourceDisk.SwapSizeMB")) * 1024         if os.path.isfile(mountpoint + "/swapfile") and os.path.getsize(mountpoint + "/swapfile") != (sizeKB * 1024):             os.remove(mountpoint + "/swapfile")         if not os.path.isfile(mountpoint + "/swapfile"):             Run("dd if=/dev/zero of=" + mountpoint + "/swapfile bs=1024 count=" + str(sizeKB))             Run("mkswap " + mountpoint + "/swapfile")         Run("chmod 600 " + mountpoint + "/swapfile")         if not Run("swapon " + mountpoint + "/swapfile"):             Log("Enabled " + str(sizeKB) + " KB of swap at " + mountpoint + "/swapfile")         else:             Error("ActivateResourceDisk: Failed to activate swap at " + mountpoint + "/swapfile")

可以看到的是,作者是先检测好mountpoint和格式,然后用Run("dd if=/dev/zero of=" + mountpoint + "/swapfile bs=1024 count=" + str(sizeKB))
 åŽ»create了相应大小的空间,其实和我们去用fallocate是一样的。这里曾经有过启用大swap空间花了很久的case,其实是因为DD也要一段时间的关系。之后我们会用fast write的方法去更新的~



            Run("mkswap " + mountpoint + "/swapfile")
        Run("chmod 600 " + mountpoint + "/swapfile")


所以其实waagent也是用了mkswap的方式去create,只不过封装好了,方便大家使用。


今天的分享就到这里,下次来测测swap和说说waagent. å¤§æ¦‚,也许是别的topic :p



‍

始发于微信公众号: IT小圈子

(915) 875-2026

Base Services

无论你是想用AWS干什么,你都不可避免的需要集成和与他们整合

EC2

Should have been called
Amazon Virtual Servers

用途

可以当作你个人的虚拟机,一台PC服务器

类比

就像你自己在linode,digitalocean租的VPS

Azure Virtual Machine

IAM

Should have been called
Users, Keys and Certs

用途
用户和密钥管理

类比

Azure AD

S3

Should have been called
Amazon Unlimited FTP Server

用途

对象存储,用来存储镜像和网站元素。很多AWS服务都和S3有集成。

类比

Azure Storage

VPC

Should have been called
Amazon Virtual Colocated Rack

用途
AWS网络组件,用来组虚拟网络,分配网段

类比

云的VLAN

Azure Vnet

Web Developer Services

网络开发服务组件,类似Azure marketplace,可以找到很多贴心的开发工具。偏Paas端

API Gateway

Should have been called
API Proxy

用途
使用该功能来创建,管理,分发API.更好的测试新版本和壮健API本身

类比

Azure api management(不尽然)

RDS

Should have been called
Amazon SQL

用途
web应用的一种可伸缩型在线数据库服务

类比

Azure Web App RDS

Route53

Should have been called
Amazon DNS + Domains

用途
帮助管理域名

类比

阿里云万网,Godady等

SES

Should have been called
Amazon Transactional Email

用途
邮件分发,提醒

类比

Sendgrid等

Cloudfront

Should have been called
Amazon CDN

用途

就是个CDN

类比

Azure CDN,国内的网宿等

CloudSearch

Should have been called
Amazon Fulltext Search

用途

类似ElasticSearch,分布式多用户全文搜索引擎

类比

Lucene, Azure search

DynamoDB

Should have been called
Amazon NoSQL

用途

MongoDB

类比

Azure mango db

Elasticache

Should have been called
Amazon Memcached

用途

分布式内存缓存系统,将数据进行缓存

类比
Redis to Go, Memcachier, Azure Redis

Elastic Transcoder

Should have been called
Amazon Beginning Cut Pro

用途
多媒体文件制作剪辑->netflix用的玩意

类比

Azure media service(不全)

Lambda

Should have been called
Javascript Execution as a Service

用途
通过Javascript函数编程方法来测试和迭代运行。有轻量的代码部署,管理和服务运行监测功能。具备一个小型代码生命周期管理的功能->很炫的新概念。

类比

暂无,新概念!类似openstack orchestration 的细化概念(误)

SQS

Should have been called
Amazon Queue

用途

消息存储.

类比
RabbitMQ, Sidekiq

Azure storage (queue)

Mobile App Developer Services

Cognito

Should have been called
Amazon OAuth as a Service

用途
终端用户redirect, auth用途

类比
OAuth.io

Azure AD

Device Farm

Should have been called
Amazon Drawer of Old Android Devices

用途
多终端同步测试

类比

Azure mobile service (误 :p)

Mobile Analytics

Should have been called
Spot on Name, Amazon Product Managers take note

用途

分析用户手机使用情况(你们的隐私早没了)

类比

Flurry, web->googleanalytics

SNS

Should have been called
Amazon Messenger

用途
发信息

类比
UrbanAirship, Twilio

Azure mobile service(future?)

Ops and Code Deployment Services

CodeCommit

Should have been called
Amazon GitHub

用途

顾名思义

类比

Microsoft code(sad)

Code Deploy

Should have been called
Not bad

用途

部署代码

类比

Azure现在用JSON直接部署虚机了!也可以VS部署

CodePipeline

Should have been called
Amazon Continuous Integration

用途

自动测试

类比
CircleCI, Travis

EC2 Container Service

Should have been called
Amazon Docker as a Service

用途

容器服务.

Elastic Beanstalk

Should have been called
Amazon Platform as a Service

用途

迁移到heroku,很著名的一个Paas

类比

heroku

Enterprise / Corporate Services

AppStream

Should have been called
Amazon Citrix

用途

Citrix

类比

Citrix

Direct Connect

Should have been called
Pretty spot on actually

用途

AWS直连到家,混合云之选

类比

Azure express route

Directory Service

Should have been called
Pretty spot on actually

用途

集成Windows AD

WorkDocs

Should have been called
Amazon Unstructured Files

用途

协同工作平台

类比
O365 Dropbox, DataAnywhere

WorkMail

Should have been called
Amazon Company Email

用途

公司内网邮件

类比
Google Apps for Domains

Workspaces

Should have been called
Amazon Remote Computer

用途

一台远程可以RDP的windows

类比

Azure Remote app

Service Catalog

Should have been called
Amazon Setup Already

用途

开发小文档!

Storage Gateway

Should have been called
S3 pretending it's part of your corporate network

用途

存储小网关,帮忙监管一下storage里的小文档

Big Data Services

Data Pipeline

Should have been called
Amazon ETL

用途

顾名思义

Elastic Map Reduce

Should have been called
Amazon Hadooper

用途
Hadoop as a service

类比

Azure Hadoop service

Glacier

Should have been called
Really slow Amazon S3

用途

归档服务

Kinesis

Should have been called
Amazon High Throughput

用途

处理动作流数据,分布式发布订阅消息系统

类比
Apache Kafka

Azure service bus(可能之后可以)

RedShift

Should have been called
Amazon Data Warehouse

用途
hdfs?

类比

Azure horonworks(VM)

Machine Learning

Should have been called
Skynet

用途
Machine learning as a service

类比

Azure machine learning

SWF

Should have been called
Amazon EC2 Queue

用途
消息处理托管服务

类比

Azure service bus

AWS Management Services

CloudFormation

Should have been called
Amazon Services Setup

用途

批量AWS资源配置更新

类比

Openstack heat, Azure resource group manager

CloudTrail

Should have been called
Amazon Logging

用途

API调用历史和日志文件分发

类比

Azure operation history

CloudWatch

Should have been called
Amazon Status Pager

用途

Dashboard

类比

Azure dashboard

Config

Should have been called
Amazon Configuration Management

用途

顾名思义

OpsWorks

Should have been called
Amazon Chef

用途

应用程序管理,网吧网管用来批量装游戏的(误)

类比

chef

Trusted Advisor

Should have been called
Amazon Pennypincher

用途

帮你找出哪里的钱可以省

类比

Azure hulu 3rd





点击原文,查看Windows Azure 工作机会~


始发于微信公众号: IT小圈子

7155780707























始发于微信公众号: IT小圈子