linux 网站建设,a5建站,用react做的网站,电脑培训班欢迎大家前往腾讯云社区#xff0c;获取更多腾讯海量技术实践干货哦~ 本文由许登博 发表于云社区专栏 原创声明#xff1a;本文首发腾讯云云社区#xff0c;未经允许#xff0c;不得转载 前言 存储网络行业协会SNIA#xff08;StorageNetworking Industry Association社区获取更多腾讯海量技术实践干货哦~ 本文由许登博 发表于云社区专栏 原创声明本文首发腾讯云·云社区未经允许不得转载 前言 存储网络行业协会SNIAStorageNetworking Industry Association快照的定义关于指定数据集合的一个完全可用拷贝该拷贝包括相应数据在某个时间点拷贝开始的时间点的映像。快照可以是其所表示的数据的一个副本也可以是数据的一个复制品。 需要注意的是快照是完全可用的拷贝但不是一份完整的拷贝至于为什么后面会详细讲。 存储快照的使用场景 场景一 存储快照是一种数据保护措施可以对源数据进行一定程度的保护通俗地讲可以理解为----后悔药。 如上图假设在t0时刻有一份完整的源数据我们在t1时刻针对这份源数据创建一份快照。 t2时刻若因为各种原因误操作、系统错误等导致源数据损毁那么我们可以通过回滚rollback快照将源数据恢复至快照创建时的状态即t1时刻这样可以尽量降低数据损失损失的数据是t1到t2之间产生的数据。 这种功能常用于银行、公安户籍、科研单位等。操作系统、软件升级或机房设备更替一般会选择在夜间或其他无生产业务时进行高危操作操作前会对数据进行快照若操作失败则将快照进行rollback将源数据恢复至操作前的状态。 场景2 前言中说过快照是一份完全可用的副本那么它完全可以被上层业务当做源数据。 如上图针对源数据创建快照后将快照卷映射给其他上层业务可以用于数据挖掘和开发测试等工作针对快照的读操作不影响源卷的数据。 这种功能常用于直播视频图片鉴黄、科研数据模拟开发测试等比如视频直播平台需要将某一段时间的视频提供给执法机构进行筛查分析那么可以通过对特定时间点保存的数据创建快照将快照映射给执法机构的业务主机去进行挖掘分析。 存储快照的实现原理 目前快照的实现方式均由各个厂商自行决定但主要技术分为2类一种是写时拷贝COWCopy On Write另一种是写重定向ROWRedirect On Write。 写时拷贝COW COW(Copy-On-Write)写时拷贝也称为写前拷贝。 创建快照以后如果源卷的数据发生了变化那么快照系统会首先将原始数据拷贝到快照卷上对应的数据块中然后再对源卷进行改写。 写操作 如上图简要示例快照创建以后若上层业务对源卷写数据XX在缓存中排队快照系统将X即将写入的位置逻辑地址上的数据Y拷贝到快照卷中对应的位置逻辑地址上同时生成一张映射表表中一列记录源卷上数据变化的逻辑地址另一列记录快照卷上数据变化的逻辑地址。我们可以看到上层业务每下发一个数据块存储上发生了两次写操作一次是源卷将数据写入快照卷即图中Y一次是上层业务将数据写入源卷即图中X。 读操作 如上图快照卷若映射给上层业务进行数据分析等用途时针对快照进行读操作时首先由快照系统判断上层业务需要读取的数据是否在快照卷中若在直接从快照卷读取若不在则查询映射表去对应源卷的逻辑地中读取这个查表并去源卷读的操作也叫读重定向。这一点恰好就解释了为什么快照是一份完全可用的副本它没有对源卷进行100%的拷贝但对上层业务来说却可以将快照看做是和源卷“一模一样”的副本。 针对源卷进行读操作时与快照卷没有数据交互。 我们可以看到快照对源卷的数据具有很好的保护措施快照可以单独作为一份可以读取的副本但并没有像简单的镜像那样一开始就占用了和源卷一样的空间而是根据创建快照后上层业务产生的数据来实时占用必需的存储空间。 快照回滚rollback 如上图回滚操作的前提条件是锁定源卷暂停对待回滚的逻辑地址上的IO操作然后通过查映射表将快照卷上的对应数据回拷到源卷中。 快照删除 采用COW技术的快照其源卷即保存着完整的实时数据因此删除快照时直接销毁了快照卷和映射表与源卷不存在数据交互。 写时重定向ROW ROW(Redirect-on-write )也称为写时重定向。 创建快照以后快照系统把对数据卷的写请求重定向给了快照预留的存储空间直接将新的数据写入快照卷。上层业务读源卷时创建快照前的数据从源卷读创建快照后产生的数据从快照卷读。 写操作 如上图简要示例快照创建以后若上层业务对源卷写数据XX在缓存中排队快照系统判断X即将写入源卷的逻辑地址然后将数据X写入快照卷中预留的对应逻辑地址中同时将源卷和快照卷的逻辑地址写入映射表即写重定向。我们可以看到上层针对源卷写入一个数据块X存储上只发生一次写操作只是写之前进行了重定向。 读操作 若快照创建以后上层业务对源卷进行读则有两种情况1若读取的数据在创建快照前产生数据是保存在源卷上的那么上层就从源卷进行读取2若需要读取的数据是创建快照以后才产生的那么上层就查询映射表从快照卷进行读取即读重定向。 若快照创建以后上层业务对快照卷进行读同样也有两种情况1若读取的数据在创建快照前产生数据是保存在源卷上的那么上层就查询映射表从源卷进行读取2若需要读取的数据是创建快照以后才产生的那么上层就直接从快照卷进行读取。 我们可以看到ROW快照也是根据创建快照后上层业务产生的数据来实时占用必需的存储空间。 快照回滚rollback 采用ROW技术的快照其源卷始终保存着快照创建前的完整数据快照创建后上层业务产生的数据都写入了快照中因此快照的回滚只是取消了对源卷的读重定向操作。通俗地说就是源卷上没有进行任何数据操作上层业务对源卷的读仅限于读源卷即不会去读取快照卷的数据。 快照删除 采用ROW技术的快照其源卷始终保存着快照创建前的完整数据快照创建后上层业务产生的数据都写入了快照中。因此若要删除快照必然要先将快照卷中的数据回拷到源卷中拷贝完成才能删除如上图。此时我们可以设想如果针对一份源数据在18:00创建了快照上层业务持续产生大量新的数据19:00又创建了快照20:00又创建了快照……那么在有多份快照的情况下如果需要删除快照就会出现多个快照向源卷回拷数据的情况可能导致回拷量非常大耗时很长。 两种技术对比 如上表COW的写时拷贝导致每次写入都有拷贝操作大量写入时源卷的写性能会有所下降而读源卷是不会受到任何影响的删除快照时只是解除了快照和源卷的关系同时删除了快照卷的数据而已。ROW在每次写入仅做了重定向操作这个操作耗时是几乎可以忽略不计的源卷的写性能几乎不会受到影响但读源卷时则需要判断数据是创建快照前还是创建快照后导致大量读时性能受到一定影响比较致命的是若源卷有多个快照在删除快照时所有快照的数据均需要回拷到源卷才可以保证源卷数据的完整性。 结语 上面简单地介绍了存储快照的实现原理实际上快照特性应用广泛其应用对象是很多的 目前主流厂商在自研产品上对上面的ROW和COW技术都有小范围的改动也有一些新兴的快照技术已经诞生但这个行业里没有最好的快照技术。技术为业务服务只有针对业务类型做好本地化适配才能达到最佳效用。 问答 消失存储过程 相关阅读 腾讯云CIS入门——Kubernetes部署 腾讯云API用Python使用腾讯云API机器翻译实例 主机迁移实践分享 此文已由作者授权腾讯云社区发布原文链接https://cloud.tencent.com/developer/article/1158686?fromSourcewaitui 欢迎大家前往腾讯云社区或关注云加社区微信公众号QcloudCommunity第一时间获取更多海量技术实践干货哦~ 海量技术实践经验尽在云加社区 转载于:https://www.cnblogs.com/qcloud1001/p/9322321.html
