openstack的问题。
展开全部
OpenStack其实有三个与存储相关的组件，这三个组件被人熟知的程度和组件本身出现时间的早晚是相符的，按熟悉程度排列如下：
Swift——提供对象存储 （Object Storage），在概念上类似于Amazon S3服务，不过swift具有很强的扩展性、冗余和持久性，也兼容S3 API
Glance——提供虚机镜像（Image）存储和管理，包括了很多与Amazon AMI catalog相似的功能。（Glance的后台数据从最初的实践来看是存放在Swift的）。
Cinder——提供块存储（Block Storage），类似于Amazon的EBS块存储服务，目前仅给虚机挂载使用。
（Amazon一直是OpenStack设计之初的假象对手和挑战对象，所以基本上关键的功能模块都有对应项目。除了上面提到的三个组件，对于AWS中的重要的EC2服务，OpenStack中是Nova来对应，并且保持和EC2 API的兼容性，有不同的方法可以实现）
三个组件中，Glance主要是虚机镜像的管理，所以相对简单；Swift作为对象存储已经很成熟，连CloudStack也支持它。Cinder是比较新出现的块存储，设计理念不错，并且和商业存储有结合的机会，所以厂商比较积极。
Swift
关于Swift的架构和部署讨论，除了官方网站，网上也有很多文章，这里就不重复.(也可以参考我之前在OpenStack中国行活动中上海站演讲的PPT)。从开发上看，最近也没有太大的结构性调整，所以我想主要说说比较适用的应用领域好了。
从我所了解的实际案例来看，Swift出现的领域有4个，(应该还有更多，希望大家看到实际用例能够指教)
1.网盘。
Swift的对称分布式架构和多proxy多节点的设计导致它从基因里就适合于多用户大并发的应用模式，最典型的应用莫过于类似Dropbox的网盘应用，Dropbox去年底已经突破一亿用户数，对于这种规模的访问，良好的架构设计是能够支撑的根本原因。
Swift的对称架构使得数据节点从逻辑上看处于同级别，每台节点上同时都具有数据和相关的元数据。并且元数据的核心数据结构使用的是哈希环，一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据,具有较好的容错性和可扩展性。另外数据是无状态的，每个数据在磁盘上都是完整的存储。这几点综合起来保证了存储的本身的良好的扩展性。
另外和应用的结合上，Swift是说HTTP协议这种语言的，这使得应用和存储的交互变得简单，不需要考虑底层基础构架的细节，应用软件不需要进行任何的修改就可以让系统整体扩展到非常大的程度。
2.IaaS公有云
Swift在设计中的线性扩展，高并发和多租户支持等特性，使得它也非常适合做为IaaS的选择，公有云规模较大，更多的遇到大量虚机并发启动这种情况，所以对于虚机镜像的后台存储具体来说，实际上的挑战在于大数据（超过G）的并发读性能，Swift在OpenStack中一开始就是作为镜像库的后台存储，经过RACKSpace上千台机器的部署规模下的数年实践，Swift已经被证明是一个成熟的选择。
另外如果基于IaaS要提供上层的SaaS 服务，多租户是一个不可避免的问题，Swift的架构设计本身就是支持多租户的，这样对接起来更方便。
3.备份归档
RackSpace的主营业务就是数据的备份归档，所以Swift在这个领域也是久经考验，同时他们还延展出一种新业务--“热归档”。由于长尾效应，数据可能被调用的时间窗越来越长，热归档能够保证应用归档数据能够在分钟级别重新获取，和传统磁带机归档方案中的数小时而言，是一个很大的进步。
4. 移动互联网和CDN
移动互联网和手机游戏等产生大量的用户数据，数据量不是很大但是用户数很多，这也是Swift能够处理的领域。
至于加上CDN，如果使用Swift，云存储就可以直接响应移动设备，不需要专门的服务器去响应这个HTTP的请求，也不需要在数据传输中再经过移动设备上的文件系统，直接是用HTTP 协议上传云端。如果把经常被平台访问的数据缓存起来，利用一定的优化机制，数据可以从不同的地点分发到你的用户那里，这样就能提高访问的速度，我最近看到Swift的开发社区有人在讨论视频网站应用和Swift的结合，窃以为是值得关注的方向。
Glance
Glance比较简单，是一个虚机镜像的存储。向前端nova（或者是安装了Glance-client的其他虚拟管理平台）提供镜像服务，包括存储，查询和检索。这个模块本身不存储大量的数据，需要挂载后台存储（Swift，S3。。。）来存放实际的镜像数据。
Glance主要包括下面几个部分：
l API service： glance-api 主要是用来接受Nova的各种api调用请求，将请求放入RBMQ交由后台处理，。
l Glacne-registry 用来和MySQL数据库进行交互，存储或者获取镜像的元数据，注意，刚才在Swift中提到，Swift在自己的Storage Server中是不保存元数据的，这儿的元数据是指保存在MySQL数据库中的关于镜像的一些信息，这个元数据是属于Glance的。
l Image store： 后台存储接口，通过它获取镜像，后台挂载的默认存储是Swift，但同时也支持Amazon S3等其他的镜像。
Glance从某种角度上看起来有点像虚拟存储，也提供API，可以实现比较完整的镜像管理功能。所以理论上其他云平台也可以使用它。
Glance比较简单，又限于云内部，所以没啥可以多展开讨论的，不如看看新出来的块存储组件Cinder，目前我对Cinder基本的看法是总体的设计不错，细节和功能还有很多需要完善的地方，离一个成熟的产品还有点距离。
Cinder
OpenStack到F版本有比较大的改变，其中之一就是将之前在Nova中的部分持久性块存储功能（Nova-Volume）分离了出来，独立为新的组件Cinder。它通过整合后端多种存储，用API接口为外界提供块存储服务，主要核心是对卷的管理，允许对卷，卷的类型，卷的快照进行处理。
Cinder包含以下三个主要组成部分
API service：Cinder-api 是主要服务接口, 负责接受和处理外界的API请求，并将请求放入RabbitMQ队列，交由后端执行。 Cinder目前提供Volume API V2
Scheduler service: 处理任务队列的任务，并根据预定策略选择合适的Volume Service节点来执行任务。目前版本的cinder仅仅提供了一个Simple Scheduler, 该调度器选择卷数量最少的一个活跃节点来创建卷。
Volume service: 该服务运行在存储节点上，管理存储空间，塔处理cinder数据库的维护状态的读写请求，通过消息队列和直接在块存储设备或软件上与其他进程交互。每个存储节点都有一个Volume Service，若干个这样的存储节点联合起来可以构成一个存储资源池。
Cinder通过添加不同厂商的指定drivers来为了支持不同类型和型号的存储。目前能支持的商业存储设备有EMC 和IBM的几款，也能通过LVM支持本地存储和NFS协议支持NAS存储，所以Netapp的NAS应该也没问题，好像华为也在努力中。我前段时间还在Cinder的blueprints看到IBM的GPFS分布式文件系统，在以后的版本应该会添加进来
到目前为止，Cinder主要和Openstack的Nova内部交互，为之提供虚机实例所需要的卷Attach上去，但是理论上也可以单独向外界提供块存储。
部署上，可以把三个服务部署在一台服务器，也可以独立部署到不同物理节点
现在Cinder还是不够成熟，有几个明显的问题还没很好解决，一是支持的商业存储还不够多，而且还不支持FC SAN，另外单点故障隐患没解决，内部的schedule调度算法也太简单。另外由于它把各种存储整合进来又加了一层，管理倒是有办法了，但是效率肯定是有影响，性能肯定有损耗，但这也是没办法的事了。
Openstack通过两年多发展，变得越来越庞大。目前光存储就出现了三种：对象存储、镜像存储和块存储。这也是为了满足更多不同的需求，体现出开源项目灵活快速的特性。总的说来，当选择一套存储系统的时候，如果考虑到将来会被多个应用所共同使用，应该视为长期的决策。Openstack作为一个开放的系统，最主要是解决软硬件供应商锁定的问题，可以随时选择新的硬件供应商，将新的硬件和已有的硬件组成混合的集群，统一管理，当然也可以替换软件技术服务的提供商，不用动应用。这是开源本身的优势！
cache直接映像中怎样判断命中与否，全相连映像怎样判断命中与否以及求块号
1．全相联映象
主存中的每一个字块可映像到Cache任何一个字块位置上，这种方式称为全相联映像。这种方式只有当Cache中的块全部装满后才会出现块冲突，所以块冲突的概率低，可达到很高的Cache命中率；但实现很复杂。当访问一个块中的数据时，块地址要与Cache块表中的所有地址标记进行比较已确定是否命中。在数据块调入时存在着一个比较复杂的替换问题，即决定将数据块调入Cache中什么位置，将Cache中那一块数据调出主存。为了达到较高的速度，全部比较和替换都要用硬件实现。
2．组相联映象
组相联映象方式是直接映象和全相联映象的一种折衷方案。这种方法将存储空间分为若干组，各组之间是直接映像，而组内各块之间则是全相联映像。它是上述两种映像方式的一般形式，如果组的大小为1，即Cache空间分为2N组，就变为直接映像；如果组的大小为Cache整个的尺寸，就变为了全相联映像。组相联方式在判断块命中及替换算法上都要比全相联方式简单，块冲突的概率比直接映像的低，其命中率也介于直接映像和全相联映像方式之间。
·替换策略和一致性问题的处理方法
Cache和存储器一样具有两种基本操作，即读操作和写操作。
当CPU发出读操作命令时，根据它产生的主存地址分为两种情形：一种是需要的数据已在Cache中，那么只需直接访问Cache，从对应单元中读取信息到数据总线；另一种是需要的数据尚未装入Cache，CPU需从主存中读取信息的同时，Cache替换部件把该地址所在的那块存储内容从主存拷贝到Cache中；若Cache中相应位置已被字块占满，就必须去掉旧的字块。常见的替换策略有两种：
1．先进先出策略（FIFO）FIFO（First In First Out）策略总是把最先调入的Cache字块替换出去，它不需要随时记录各个字块的使用情况，较容易实现；缺点是经常使用的块，如一个包含循环程序的块也可能由于它是最早的块而被替换掉。
2．最近最少使用策略（LRU）LRU（Least Recently Used）策略是把当前近期Cache中使用次数最少的那块信息块替换出去，这种替换算法需要随时记录Cache中字块的使用情况。LRU的平均命中率比FIFO高，在组相联映像方式中，当分组容量加大时，LRU的命中率也会提高。
当CPU发出写操作命令时，也要根据它产生的主存地址分为两种情形：一种是不命中时，只向主存写入信息，不必同时把这个地址单元所在的整块内容调入Cache中；另一种是命中时，这时会遇到如何保持Cache与主存的一致性问题，通常有三种处理方式：
1．直写式（write through）即CPU在向Cache写入数据的同时，也把数据写入主存以保证Cache和主存中相应单元数据的一致性，其特点是简单可靠，但由于CPU每次更新时都要对主存写入，速度必然受影响。
2．缓写式（post write）即CPU在更新Cache时不直接更新主存中的数据，而是把更新的数据送入一个缓存器暂存，在适当的时候再把缓存器中的内容写入主存。在这种方式下，CPU不必等待主存写入而造成的时延，在一定程度上提高了速度，但由于缓存器只有有限的容量，只能锁存一次写入的数据，如果是连续写入，CPU仍需要等待。
3．回写式（write back）即CPU只向Cache写入，并用标记加以注明，直到Cache中被写过的块要被进入的信息块取代时，才一次写入主存。这种方式考虑到写入的往往是中间结果，每次写入主存速度慢而且不必要。其特点是速度快，避免了不必要的冗余写操作，但结构上较复杂。
此外，还有一种设置不可Cache区（Non－cacheable Block）的方式，即在主存中开辟一块区域，该区域中的数据不受Cache控制器的管理，不能调入Cache，CPU只能直接读写该区域的内容。由于该区域不与Cache发生关系，也就不存在数据不一致性问题。目前微机系统的BIOS设置程序大多允许用户设置不可Cache区的首地址和大小。
微白蛋白(UMA) 是什么意思
微量白蛋白尿是指在尿中出现微量白蛋白。白蛋白是一种血液中的正常蛋白质，但在生理条件下尿液中仅出现极少量白蛋白。微量白蛋白尿反映肾脏异常渗漏蛋白质。
尿微量白蛋白是评估肾脏受损程度：通常来说要注意的是糖尿病和高血压，希望你到肾炎科去仔细看看，具体是那块出现了疾病。
主存与cache有什么区别
主存储器一般指的是内存，cache指的是高速缓存，高速缓存内是CPU和内存之间交换的数据，内存里面一般是CPU和硬盘之间的数据，由于硬盘的读写速度远远低于CPU的处理速度，所以要把数据预读在内存里，另外，内存还存放着系统当前正在运行的数据。还有一种虚拟内存，是用于解决内存不足的问题而产生的。