存储快照

测试fFreeNas做快照和主备容灾

匿名 (未验证) 提交于 2019-12-03 00:39:02
FreeNas使用ZFS文件系统,支持一些存储虚拟化功能,如快照功能。为了保证数据可靠性,不会丢失,利用快照功能对数据进行定时自动快照保存,同时将快照同时复制同步到另一台同样的FreeNas存储上,实现主备容灾。两台FreeNas都是虚拟机,所有配置一样,主端为名称为F1,备端名称为F2 参考: http://doc.freenas.org/11/storage.html#examples-common-configuration 定期快照 定期快照任务允许在给定时间点安排创建ZFS卷和数据集的只读版本。可以快速创建快照,如果数据变化很小,则新快照占用的空间非常小。例如,没有文件更改的快照占用0 MB的存储空间,但随着对文件的更改,快照大小会更改以反映更改的大小。 快照提供了一种保存文件历史记录的巧妙方法,提供了恢复旧版本甚至已删除文件的方法。出于这个原因,许多管理员经常拍摄快照(可能每十五分钟一次),将它们存储一段时间(可能是一个月),然后将它们存储在另一个系统上(通常使用 复制任务)。这种策略允许管理员将系统回滚到特定时间点。如果发生灾难性丢失,可以使用异地快照将系统还原到上次快照的时间。 在F1上,配置定期快照 配置定期快照的时间段,保存时间等信息,本次为了测试,将定期快照设定为周一到周五,每10分钟执行一次,保存2周 创建完成后如下图所示: 在快照里面

Chrome开发者工具详解-Profiles面板

匿名 (未验证) 提交于 2019-12-03 00:26:01
如果上篇中的Timeline面板所提供的信息不能满足你的要求,你可以使用Profiles面板,利用这个面板你可以追踪网页程序的 内存泄漏 问题,进一步提升程序的JavaScript 执行性能 。 概述 当前使用的Chrome最新版为 54.0.2840.71 ,这个版本的Profiles面板比之前提供的功能更多也更强大,下面是该面板所包含的功能点: Record JavaScript CPU Profile Take Heap Snapshot Record Allocation Timeline Record Allocation Profile Record JavaScript CPU Profile简介 通过选择 Record JavaScript CPU Profile ,然后点击 Start ,结合你所要分析的具体场景,你可以重新加载网页,或者在网页上进行交互,甚至什么都不操作。最后点击 Stop ,完成记录操作。 有三种不同的视图可供选择: Chart Heavy(Bottom Up) Tree(Top Down) 我们以 Chart 视图为例分析一下JS的执行的性能情况: 该视图会以时间顺序展示CPU的性能情况,视图主要分成两块: Overview Call Stacks 视图中的函数颜色不同于其它的面板,这里面的函数颜色标记是随机显示的

LXC容器

匿名 (未验证) 提交于 2019-12-03 00:17:01
官方给出的LXC未来的目标是: LXC将Linux进程沙盒化,使得进程之间相互隔离,并且能够控制各进程的资源分配。 lxc 用容器的方式仿真了一个类似虚拟机的操作体验,并避免了虚拟机额外的系统负载。lxc利用cgroup和namespace在linux应用层创建了一个“虚拟机”(隔离的裸露文件系统),无法有效支持跨主机之间的容器迁移、管理复杂(lxd解决了这些问题)。 lxc和docker不同地方在于lxc包含完整的操作系统,是一个系统容器。 Docker的底层使用了LXC来实现的,但docker对lxc封装,提供了更好的操作性和移植性。 Docker容器将应用和其依赖环境全部打包到一个单一对象中,在不包含完整的操作系统的情况下就能运行普通应用,更加轻量级,可移植性更好。 所以它成为了PaaS(比如Kubernates)平台的基石。 除了lxc底层基础之外, Docker还提供了一个具有以下强大功能的高级工具: 跨机器的便携式部署。 Docker定义了一种将应用程序及其所有依赖绑定到一个单独对象中的格式,该对象可以被传输到任何启用docker的机器上,并在那里执行,保证暴露给应用程序的执行环境是相同的。 Lxc实现了流程沙盒,这是便携式部署的重要先决条件,但单靠这一点对于便携式部署来说是不够的。如果您向我发送了一个安装在自定义lxc配置中的应用程序的副本

(6)ceph RBD 复制

匿名 (未验证) 提交于 2019-12-02 23:56:01
Ceph 存储集群可以从RBD的快照中创建写时复制 (COW 副本),这就是 Ceph 的快照分层。 Ceph 的这个分层特性允许客户端创建 Ceph RBD 的多个即时副本, 这个特性对云平台和虚拟化平台非常有 ,例如 OpenStack 、CloudStack 和Qemu/ KVM 这些平台通常'以快照的形式保护含有 OS/VM 镜像的Ceph RBD 镜像 ,然后通过不断复制这个快照来创建新的虚拟机 /实例 ,快照是只读的,但是 COW 副本则是完全可写的; Ceph 的这个特性为云平台带来巨大的灵活性,并且对于云平台非常有用,下图显示了 RADOS 块设备、 RBD 快照和COW 快照副本之间的关系。 每一个复制的镜像(子镜像)都包含它的父快照的引用,用于读取镜像数据。 因此,父快照在用于复 制之前应该处于被保护状态。当有数据写入COW 复制的镜像时,它会为自己存储新的数据引用。 COW 复制的镜像与 RBD是一 样的。 它们都非常灵活,类似于 RBD ,也就是说,它们可写, 可调整容量,可以创建新的快照,将来还可以复制。 RBD 镜像的类型定义了它所支持的特性,在Ceph 中,有两种 类型的RBD 镜像:format-l和 form t-2, format-l和 format-2 类型的 RBD 镜像 都支持快 照特性。然而,分层特性( 也就是 COW 特性)只有

存储快照实现原理

匿名 (未验证) 提交于 2019-12-02 23:56:01
存储快照实现原理 https : //www.cnblogs.com/tcicy/p/8444306.html 存储快照有两种实现方式:COW(写时复制 Copy-On-Write )、ROW(写重定向 Redirect-On-Write ),两种实现方法有区别,造成读写性能、应用场景有比较大的区别。 COW: 原理见下图(从网上找的,没自己画)。 1)原卷数据是A~G。此卷Metedata像指针一样指向这些数据。 2)当做快照时,重新复制一份Metedata,并且也指向这些A~G数据。 3)当有数据要写入到源卷时(下图写入D'),写入到D的原位置之前,需要把D拷贝出放到一个新位置。然后修改快照的Metedata的其中一个指针指向拷贝出的位置[D](图中是Snapshot data的存储位置)。同时,把D’写入到D原来的位置。 此方式可以看出,源卷的Metedata的是没有变化的。对原卷是连续的数据,多次快照,多次写之后还是 连续的数据 ,因此读性能或者对单个位置的多次写性能都不会有很大的影响。 但是, 快照的数据是非连续的 ,如数据ABCEFG还是在源卷的位置,是连续数据。而数据D在存储的其他位置,非连续。 如果多次快照,不同位置的多次读写后,快照的数据可能就比较混乱。造成对快照的读写延时较大。 应用场景: 这种实现方式在第一次写入某个存储位置时需要完成一个读操作(读原位置的数据

Mobx vs Mobx State Tree(MST)

匿名 (未验证) 提交于 2019-12-02 23:45:01
Mobx State Tree(MST)他建立在MobX的基础之上, MobX速度快,但不提供开箱即用的任何组织结构,因此集中获取整个状态的快照, 从快照中的恢复状态,时间旅行要么不可行,要么由开发人员手动支持。 MST通过将单独的存储组织到交互式和交互式节点的单个树中来支持所有上述功能。 MST的中心是活树的概念。该树由可变但受严格保护的对象组成,这些对象富含运行时类型信息。换句话说,每个树具有形状(类型信息)和状态(数据)。 从这个活树中,自动生成不可变的,结构上共享的快照。 然而,所有这些都需要付出一些代价,而MST通常比纯MobX慢一些。因此,不需要这些功能,请只使用MobX。

redis 安装配置

被刻印的时光 ゝ 提交于 2019-12-02 17:47:50
1,下载编译安装redis http://www.redis.cn/download.html 下载完成,使用rz命令上传至linux 服务器 tar -xvf redis-5.0.5.tar.gz #解压源码包 mv redis-5.0.5 /usr/local/redis #将源码包移动到/usr/local/目录下,重命名为redis cd /usr/local/redis/ #cd 到源码目录里 make #编译 中间有两个报错,解决 #没有安装gcc 包,yum install gcc -y 解决 #加个环境变量一起编译    make MALLOC=libc 用这句命令能正常编译 make install #安装编译完成的程序,也可以不用安装,cd 到src目录 执行也行 cd /usr/local/bin/ #这个目录是安装完成后 生成的脚本,打开关闭 客户端工具都在里面 2.配置 配置文件,启动 关闭 redis vim /usr/local/redis/redis.conf #配置 redis 配置文件,修改以下选项 bind 0.0.0.0 #监听IP 0.0.0.0 表示此计算机所有IP都监听 daemonize yes #是否后台启动redis,打开 protected-mode no # redis的安全机制,打开可能会报错 #requirepass

如何安装虚拟机以及对虚拟机的管理

[亡魂溺海] 提交于 2019-12-02 06:12:34
1.手动安装虚拟机 前提==:liunx 系统镜像已下载好 说明 :安装图形化虚拟机 步骤一:在真机中输入virt-manager 可以弹出如下界面: 步骤二:点击左上角的小电视,出现如下界面,选择本地安装,点击forward进行下一步 步骤三:点击Browse,选择虚拟机存放路径,点击下一步 步骤四:选择分配内存大小和选择几核cpu,点击下一步Forward 步骤五:选择分配硬盘大小,下一步 步骤六:填写虚拟机名字,勾选安装手动设置配置,点击完成 步骤七:将node虚拟机的硬盘和网卡均设置为 virtIO 虚拟化,点击应用 步骤八:点击开始安装 步骤八:点击Install Red hat 企业板 步骤九:点击continue 继续 步骤十:设置相关参数 (1)时区:Asia shanghai (2)支持的语言:添加中文 (3)软件安装选择:带GUI (4)选则标准安装 步骤十一:手动分区,标准分区 步骤十二:重启 2.虚拟机管理命令 命令为virsh virsh list 列出所有正在开启的虚拟机 virsh list --all 列出系统中所有的虚拟机 virsh destroy vmname 关闭vnmane虚拟机(断电) virsh shutdown vmname 关闭vmname虚拟机(正常关机) virsh start vmname 开启vmname虚拟机 virt

Ceph分布式文件系统

房东的猫 提交于 2019-12-01 21:48:56
什么是分布式文件系统 分布式文件系统(Distributed File System)是指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点相连 分布式文件系统的设计基于客户机/服务器模式 常用的分布式文件系统: Lustre 、 Hadoop 、 FastDFS 、 Ceph 、 GlusterFS 什么是Ceph Ceph是一个分布式文件系统 具有高扩展、高可用、高性能的特点 Ceph可以提供对象存储、块存储、文件系统存储 Ceph可以提供EB级别的存储空间(EB->PB->TB->GB) 软件定义存储(Software Defined Storage)作为存储行业的一大发展趋势,已经越来越受到市场的认可 Ceph组件 OSDs:存储设备 Monitors:集群监控组件 RBD:对象存储网关 MDSs:存放文件系统的元数据(对象存储和块存储不需要该组件) Client:ceph客户端 准备四台虚拟机,其三台作为存储集群节点,一台安装为客户端,实现如下功能: 创建1台客户端虚拟机 创建3台存储集群虚拟机 配置主机名、IP地址、YUM源 修改所有主机的主机名 配置无密码SSH连接 配置NTP时间同步 创建虚拟机磁盘 拓扑结构如图。 一:安装前准备 (1)物理机为所有节点配置yum源服务器。 [root@room9pc01 ~]# yum -y

Maven 快照

不羁的心 提交于 2019-12-01 10:33:29
概述 大型应用软件一般由多个模块组成,一般它是多个团队开发同一个应用程序的不同模块,这是比较常见的场景。例如,一个团队正在对应用程序的应用程序,用户界面项目( app-ui.jar:1.0 ) 的前端进行开发,他们使用的是数据服务工程 ( data-service.jar:1.0 )。 现在,它可能会有这样的情况发生,工作在数据服务团队开发人员快速地开发 bug 修复或增强功能,他们几乎每隔一天就要释放出库到远程仓库。 现在,如果数据服务团队上传新版本后,会出现下面的问题: 数据服务团队应该发布更新时每次都告诉应用程序 UI 团队,他们已经发布更新了代码。 UI 团队需要经常更新自己 pom.xml 以获得更新应用程序的版本。 为了处理这类情况,引入快照的概念,并发挥作用。 什么是快照? 快照(SNAPSHOT)是一个特殊版本,指出目前开发拷贝。不同于常规版本,Maven 每生成一个远程存储库都会检查新的快照版本。 现在,数据服务团队将在每次发布代码后更新快照存储库为: data-service:1.0-SNAPSHOT 替换旧的 SNAPSHOT jar 。 快照与版本 在使用版本时,如果 Maven 下载所提到的版本为 data-service:1.0 ,那么它永远不会尝试在库中下载已经更新的版本 1.0。要下载更新的代码,data-service 的版本必须要升级到 1.1。