最近见到一个客户，主要使用Azure的存储服务，保存海量归档数据，每年主要cloud的花费都在存储上，并且客户的数据量还在迅猛增长。客户对Azure存储服务的安全性非常满意，避免了本地保存的高成本以及数据管理、安全方面的资金及人力投入。但是随着存储量增加，成本也急剧上升（客户数据不能删除）。

为客户合理规划存储服务，可大大降低客户的使用成本。下边，就谈谈通过冷热存储分层的方式来降低客户开销。

​ 随着IT的发展，无论是企业还是个人，文件类的数据越来越多，随之而来的文件传递、共享、同步等需求愈加旺盛。传统的文件拷贝、U盘传递、ftp等方式已无法满足需要。前些年公有网盘迅猛发展，但是由于各种原因，最近各种公有网盘服务都逐渐停止或者缩减服务项目，不能提供很好的服务，并且敏感数据放入公有网盘有数据泄露的风险。

​ 本文将介绍如何通过Azure搭建企业或个人的私有云盘来实现数据转移、共享、备份等功能。

前言

存储系统是整个IT系统中性能最薄弱的一个环节，很多时候在做系统调优时会发现大多数情况下短板都在存储。

对存储系统的性能评估一般会从三个方面着手：IOPS（每秒能处理多少IO）、延时（每个IO发出请求后多长时间能完成）、带宽（每秒能处理多大量的数据）。这三个指标相互影响（带宽=IO尺寸*IOPS）有时候甚至相互矛盾，不同应用场景的要求也不一样。例如在数据库环境中，要求IOPS尽量高，延时尽量低，而数据库一般IO尺寸大约在4KB、8KB，所以即使很高的IOPS例如5万，带宽也就约400MB/s，还不到一个SFP的接口带宽；而在大文件处理时，由于IO尺寸很大，所以IOPS并不高，而且这种情况下延时并不敏感，存储系统在处理这种大尺寸IO时，会屏蔽cache，通常延时会表现很大。总体而言，IOPS是用作评估存储系统性能最常用的一个指标。

但是，IOPS很难准确的去评估存储性能，同样系统，在不同的IO大小、读写比例、随机还是顺序、测试时间长短、测试数据大小等都会对测试结果产生很大偏差，特别现在AFA（全闪存阵列）越来越普及，测试时是否导致垃圾回收机制、磁盘累计写入数据量大小等也会带来对结果的影响。所以很多传统存储厂商如EMC等拒绝公布产品的IOPS测试值，而是强调根据用户的实际环境来做性能评估（例如Exchange的jetstress、oracle的orion等）。

Azure也公布了一些存储的性能参数，本文通过对Azure下磁盘进行测试，来实际评估Azure的磁盘性能。

这几天遇到几个客户都有在Azure上存取文件的需求。当然，可以通过在Azure里建立虚机并配置虚机相关的文件访问服务如ftp、nfs、http等来解决，但是配置复杂，还需要考虑网络、HA等因素。而Azure本身提供了较为丰富的存储服务，可以满足大部分用户一般的文件存储访问需求。

通常，Azure提供了两种文件存储服务：File和Blob。File提供smb2.1和smb3访问，对于基于internet的文件访问，我们就要使用Blob了。

下边，简单探讨一下Blob的文件访问操作。

Azure网络安全解析

作为公有云最重要环节之一，网络安全一直是Azure的重中之重。在Azure中，多种安全技术共同构成了立体的网络保护：

其中，最常和用户打交道的就是NSG（网络安全组），vm和网络的连接、不同子网间的连接等都可以用NSG来做限制和保护。

前言

公有云基础架构与传统IT架构有很大的区别，特别是在网络和存储方面。
以存储为例，Azure没有share disk，所以在传统的aluster、rac等无法部署，虽然有人通过在vm安装配置软iscsi target方式实现，但是效率太低，而且不稳定。从公有云设计思路来看，我们需要尽可能的使用Paas服务，将底层的安全和稳定性交给公有云去解决。如果一定需要通过vm来实施的组件，尽可能无状态化。

前言

Azure作为公有云，由虚机、网络、存储等各种资源组成，用户根据需要随时增减资源，按实际用量付费即可，非常方便。
但是在订阅里，每种资源都有一定配额，例如azure.cn的1元试用账号，虚机（以下简称vm）的活动cpu核（以下简称core）总数不能超过4个，意味着用户可以创建很多vm，但是同时开机的vm的总core数量不能超过4个。

去年一时兴起，在Godaddy上买了域名，搭建了一个博客，陆陆续续写了几篇blog，不过由于一些不可描述的原因，访问时快时慢，弄得最后没啥兴趣，也很久不更新了。前段时间因为更换工作，很多东西需要从头再学，考虑找个地方把学习的东西汇总一下，于是又想把blog弄起来。