记录关于Devops运维,虚拟化容器云计算,数据库,网络安全等各方面问题,
        Centos8安装podman容器+portainerUI+podman API启用方法一,安装podman容器软件。官方文档:https://podman.io/getting-started/installationpodman 目前只支持linux版本,windows和mac可以用Remote Client连接到远程的Podman上sudo yum -y install podman二,解决一些兼容问题。问题1:user namespaces are not enabled in /proc/sys/user/max_user_namespaces解决办法:# centos 7默认关闭了 user namespace,需要手动打开echo 10000 > /proc/sys/user/max_user_namespacesgrubby --args="user_namespace.enable=1" --update-kernel="$(grubby --default-kernel)"echo "user.max_user_namespaces=10000" >> /etc/sysctl.conf问题2:Error: failed to mount overlay for metacopy check with "nodev,metacopy=on" options: invalid argument解决办法:vi /etc/containers/storage.conf# 旧版kernel配置不支持podman某些特性,需要注释掉mountopt#mountopt = "nodev,metacopy=on"问题3:ERRO[0000] cannot find UID/GID for user xxxx: No subuid ranges found for user "xxx&q...
K8S Node节点禁止调度(平滑维护)方式- cordon,drain,delete cordon、drain和delete三个命令都会使node停止被调度,后期创建的pod不会继续被调度到该节点上,但操作的暴力程度却不一样。   一、cordon 停止调度 (不可调度,临时从K8S集群隔离) 影响最小,只会将node标识为SchedulingDisabled不可调度状态。 之后K8S再创建的pod资源,不会被调度到该节点。 旧有的pod不会受到影响,仍正常对外提供服务。 禁止调度命令"kubectl cordon node_name"。 恢复调度命令"kubectl uncordon node_name"。(恢复到K8S集群中,变回可调度状态)   二、drain 驱逐节点 (先不可调度,然后排干) 首先,驱逐Node上的pod资源到其他节点重新创建。 接着,将节点调为SchedulingDisabled不可调度状态。 禁止调度命令"kubectl drain node_name --force --ignore-daemonsets --delete-local-data" 恢复调度命令"kubectl uncordon node_name"。(恢复到K8S集群中,变回可调度状态) drain方式是安全驱逐pod,会等到pod容器应用程序优雅停止后再删除该pod。 drain驱逐流程:先在Node节点删除pod,然后再在其他N...
Mycat 读写分离、主从切换、分库分表的操作记录系统开发中,数据库是非常重要的一个点。除了程序的本身的优化,如:SQL语句优化、代码优化,数据库的处理本身优化也是非常重要的。主从、热备、分表分库等都是系统发展迟早会遇到的技术问题问题。Mycat是一个广受好评的数据库中间件,已经在很多产品上进行使用了。下面就针对Mycat的基础知识和应用做一总结性梳理,这些内容有的是从网上收集的,有的是自己做的测试验证信息,如有错误,烦请谅解和指出! 一、MyCat简单介绍MyCat是一个开源的分布式数据库系统,是一个实现了MySQL协议的服务器,前端用户可以把它看作是一个数据库代理(类似于Mysql Proxy),用MySQL客户端工具和命令行访问,而其后端可以用MySQL原生协议与多个MySQL服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信,其核心功能是分表分库,即将一个大表水平分割为N个小表,存储在后端MySQL服务器里或者其他数据库里。 MyCat发展到目前的版本,已经不是一个单纯的MySQL代理了,它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流数据库,也支持MongoDB这种新型NoSQL方式的存储,未来还会支持更多类型的存储。而在最终用户看来,无论...
ProxySQL 实现Mysql读写分离 - 部署手册 ProxySQL是一个高性能的MySQL中间件,拥有强大的规则引擎。ProxySQL是用C++语言开发的,也是percona推的一款中间件,虽然也是一个轻量级产品,但性能很好(据测试,能处理千亿级的数据),功能也足够,能满足中间件所需的绝大多数功能。 ProxySQL具备了很多优质特性,具体总结如下:-> 连接池,而且是multiplexing-> 主机和用户的最大连接数限制-> 自动下线后端DB     -> 延迟超过阀值     ->  ping 延迟超过阀值     ->  网络不通或宕机-> 强大的规则路由引擎     -> 实现读写分离     -> 查询重写     -> sql流量镜像-> 支持prepared statement-> 支持Query Cache-> 支持负载均衡,与gelera结合自动failover-> 可定制基于用户、基于schema、基于语句的规则对SQL语句进行路由。换句话说,规则很灵活。基于schema和与语句级的规则,可以实现简单的sharding。-> 可缓存查询结果。虽然ProxySQL的缓存策略比较简陋,但实...
Ceph-deploy快速部署Ceph分布式存储 之前已详细介绍了Ceph分布式存储基础知识,下面简单记录下Centos7使用Ceph-deploy快速部署Ceph环境:1)基本环境 192.168.10.220 ceph-admin(ceph-deploy) mds1、mon1(也可以将monit节点另放一台机器) 192.168.10.239 ceph-node1 osd1 192.168.10.212 ceph-node2 osd2 192.168.10.213 ceph-node3 osd3 ------------------------------------------------- 每个节点修改主机名 # hostnamectl set-hostname ceph-admin # hostnamectl set-hostname ceph-node1 # hostnamectl set-hostname ceph-node2 # hostnamectl set-hostname ceph-node3 ------------------------------------------------- 每个节点绑定主机名映射 # cat /etc/hosts 192.168.10.220 ceph-admin 192.168.10.239 ceph-node1 192.168.10.212 ceph-node2 192.168.10.213 ceph-node3 ------------------------------------------------- 每个节点确认连通性 # ping -c 3 ceph-admin # ping -c 3 ceph-node1 # ping -c 3 ceph-node2 # ping -c 3 cep...
Centos7下ELK+Redis日志分析平台的集群环境部署记录 之前的文档介绍了ELK架构的基础知识,日志集中分析系统的实施方案:- ELK+Redis- ELK+Filebeat - ELK+Filebeat+Redis- ELK+Filebeat+Kafka+ZooKeeper ELK进一步优化架构为EFK,其中F就表示Filebeat。Filebeat即是轻量级数据收集引擎,基于原先Logstash-fowarder 的源码改造出来。换句话说:Filebeat就是新版的 Logstash-fowarder,也会是ELK Stack在shipper端的第一选择。 这里选择ELK+Redis的方式进行部署,下面简单记录下ELK结合Redis搭建日志分析平台的集群环境部署过程,大致的架构如下: + Elasticsearch是一个分布式搜索分析引擎,稳定、可水平扩展、易于管理是它的主要设计初衷 + Logstash是一个灵活的数据收集、加工和传输的管道软件 + Kibana是一个数据可视化平台,可以通过将数据转化为酷炫而强大的图像而实现与数据的交互将三者的收集加工,存储分析和可视转化整合在一起就形成了ELK。 基本流程:1)Logstash-Shipper获取日志信息发送到redis。2)Redis在此处的作用是防止ElasticSearch服务异常导致丢失日志,提供消息队列的作用。[注意:缓存到redis里的日志被输送到elasticsearch之后,在redis里的对应db库里...
Mongodb主从复制/ 副本集/分片集群介绍 前面的文章介绍了Mongodb的安装使用,在 MongoDB 中,有两种数据冗余方式,一种 是 Master-Slave 模式(主从复制),一种是 Replica Sets 模式(副本集)。 Mongodb一共有三种集群搭建的方式: Replica Set(副本集)、 Sharding(切片) Master-Slaver(主从)【目前已不推荐使用了!!!】 其中,Sharding集群也是三种集群中最复杂的。 副本集比起主从可以实现故障转移!!非常使用! mongoDB目前已不推荐使用主从模式,取而代之的是副本集模式。副本集其实一种互为主从的关系,可理解为主主。 副本集指将数据复制,多份保存,不同服务器保存同一份数据,在出现故障时自动切换。对应的是数据冗余、备份、镜像、读写分离、高可用性等关键词; 而分片则指为处理大量数据,将数据分开存储,不同服务器保存不同的数据,它们的数据总和即为整个数据集。追求的是高性能。 在生产环境中,通常是这两种技术结合使用,分片+副本集。 一、先说说mongodb主从复制配置 主从复制是MongoDB最常用的复制方式,也是一个简单的数据库同步备份的集群技术,这种方式很灵活.可用于备份,故障恢复,读扩展等. 最基本的设置方式就是建立一个...
Redis哨兵模式(sentinel)学习总结及部署记录(主从复制、读写分离、主从切换) Redis的集群方案大致有三种:1)redis cluster集群方案;2)master/slave主从方案;3)哨兵模式来进行主从替换以及故障恢复。 一、sentinel哨兵模式介绍Sentinel(哨兵)是用于监控redis集群中Master状态的工具,是Redis 的高可用性解决方案,sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel是redis高可用的解决方案,sentinel系统可以监视一个或者多个redis master服务,以及这些master服务的所有从服务;当某个master服务下线时,自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。 sentinel可以让redis实现主从复制,当一个集群中的master失效之后,sentinel可以选举出一个新的master用于自动接替master的工作,集群中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台,防止某一台sentinel无法连接到master导致误切换。其结构如下: Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案,当用Redis做Master-slave的高可用方案时,假如master宕机了,Redis本身(包括它的很多客户端)都没有实现自动进行主备切换,而Re...
kafka 基础知识梳理及集群环境部署记录 一、kafka基础介绍 0. kakfa概述 Kafka是最初由Linkedin公司开发,是一个分布式、支持分区的(partition)、多副本的(replica)开源消息系统,由Scala写成,是由Apache软件基金会开发的一个开源消息系统项目,该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。kafka基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编写,Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。 kafka是一个分布式消息队列:生产者、消费者的功能。它提供了类似于JMS的特性,但是在设计实现上完全不同,此外它并不是JMS规范的实现。Kafka对消息保存时根据Topic进行归类,发送消息者称为Producer,消息接受者称为Consumer,此外kafka集群有多个kafka实例组成,每个实例(server)成为broker。无论是kafka集群,还是producer和consumer都依赖于zookeeper集群保存一些meta信息,来保证系统可用性 kafka是一种高吞吐量的分布式发布订阅消息系统,它可以...
RocketMQ 简单梳理 及 集群部署笔记 一、RocketMQ 基础知识介绍Apache RocketMQ是阿里开源的一款高性能、高吞吐量、队列模型的消息中间件的分布式消息中间件。 上图是一个典型的消息中间件收发消息的模型,RocketMQ也是这样的设计,简单说来RocketMQ具有以下特点:1)是一个队列模型的消息中间件,具有高性能、高可靠、高实时、分布式特点。2)Producer、Consumer、队列都可以分布式。3)Producer向一些队列轮流发送消息,队列集合称为Topic,Consumer如果做广播消费,则一个consumer实例消费这个Topic对应的所有队列,如果做集群消费,则多个Consumer实例平均消费这个topic对应的队列集合。4)支持严格的消息顺序;5)提供丰富的消息拉取模式6)高效的订阅者水平扩展能力7)实时的消息订阅机制8)亿级消息堆积能力9)较少的依赖10)支持Topic与Queue两种模式;11)同时支持Push与Pull方式消费消息; 消息队列的应用场景1)异步处理将不是必须的业务逻辑,进行异步处理,比如注册之后短信、邮箱的发送 2)应用解耦订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。库存系统:订阅下单的消息,采用拉/推的方式,获取下单信息,库存...
    总共252页,当前第12页 | 页数:
  1. 2
  2. 3
  3. 4
  4. 5
  5. 6
  6. 7
  7. 8
  8. 9
  9. 10
  10. 11
  11. 12
  12. 13
  13. 14
  14. 15
  15. 16
  16. 17
  17. 18
  18. 19
  19. 20
  20. 21
  21. 22