OVN系列4 -- L2 & L3 Network

Posted 2023-04-11

参考技术A 配置一个简单的L2 和 L3 Network 测试拓扑，包含两个L2 Network（logic switch），每个L2 Network连接两个vm（用netns模拟），包含一个VPC Router（logic router）连接两个L2 Network，使其能够三层互通。
这里将模拟云网络东西向流量的二三层互通。不涉及南北向流量。

逻辑拓扑如下：

分别测试同主机互通和跨主机互通，所以我们将"400-vm2" 这个虚拟机单独放到Node节点上，其他VM放到Central节点上。
物理拓扑如下：

OVN L2功能包括

1、 配置sw-300，同主机二层互联

2、配置sw-400，跨主机二层互联

OVN L3的功能包括

虚拟机vm-300-1、vm-300-2位于VPC网络sw-300中，二层互通；
虚拟机vm-400-1、vm-400-2位于VPC网络sw-400中，跨主机二层互通；
两个VPC网络中的VM相互之间三层互通。

OVN 逻辑拓扑和我们的配置一一对应，表达了传统意义上的拓扑，OVN根据已经配置的业务产生逻辑流表 （ovn-sbctl list Logical_Flow）。
逻辑拓扑可以通过 通过ovn-nbctl show命令 查看，如下，可以看到逻辑datapath、逻辑port，以及他们的各种属性配置。

OVN的物理拓扑当然是在ovs中的，其logic sw和logic router都是在ovs bridge br-int中实现的，是非常抽象的，数据面datapath网络功能基本都是通过流表实现；在物理拓扑形成前，如VM nic加入LS之前，逻辑流表不会转换为实际流表；

ovn-sbctl show显示了OVN Southbound DB信息，我们可以看到其已经很接近物理拓扑了，物理节点上的控制器就是通过监控Southbound DB来配置ovs的。
其中有个Chassis的概念，等同于计算节点（HyperV），后面的一些需要指定节点信息的功能，如集中式公网出口网关、LB公网入口等都会指定这个信息；

ovs使用流表转发，ovn即使能够实现如此多的网络功能，也都是通过流表抽象实现的。ovn将网络业务逻辑抽象为业务流表，节点上的控制器再将逻辑流表转化为实际ovs流表。
同逻辑拓扑和物理拓扑类似，逻辑流表也更加的可读易懂。通过ovn-sbctl list Logical_Flow 显示。

如下显示一条arp reply的逻辑流表和实际流表，结合起来读事半功倍。

实际流表中使用了很多寄存器存放元数据，在流的整个pipeline中生效。下面列出了常用的几个寄存器的作用。

虚拟机跨主机的流量需要通过tunnel口发出，但在这之前，转发流程已经在源主机上确认了，即当前是在那个逻辑设备上（metadata）、从那个口收（reg14）、从那个口出（reg15）都已经确认，从tunnel口发出时，这些信息都会设置到tunnel的option中（可扩展的元数据），到了对端主机后，再取出设置到对应的寄存器中。
如下： 逻辑设备设置到NXM_NX_TUN_ID 中，in_port 和 out_port设置到tunnel的元数据 NXM_NX_TUN_METADATA0 中。

流表中有很多controller action，都是需要上送控制器处理的逻辑，基本做两件事情：

mysq'l系列之10.mysql优化&权限控制

网站打开慢如何排查

1.打开网页, 用谷歌浏览器F12, 查看network: 哪个加载时间长就优化哪个

 

2.如果是数据库问题

2.1 查看大体情况

# top

# uptime  //load average 负载

mysql> show full processlist;

2.2 查看慢查询日志:

long_query_time = 1

log-slow-queries = /data/3306/slow.log

日志分析工具:

mysqldumpslow  mysqlsla  myprofi  mysql-explain-slow-log  mysqllogfilter

2.3 观察sql语句执行情况:

mysql> explain....

 

2.4 查看条件字段field的值的唯一性

mysql> select count(distinct ader) from tb1;

2.5 where条件语句最后用等号, 那样效率最高

2.6 查看report

./mysqlreport --user=root --password=123456 --socket=/usr/local/mysql/tmp/mysql.sock

 

 

 

搜索对网站数据库的压力

1.从业务上实现用户登录后才能搜索, 减少搜索次数 (如果这个逻辑不行, 就放弃)

2.如果有大量的频繁搜索, 一般是爬虫在爬网站, 那么分析web日志封掉此ip

3.配置多个主从同步, 实现读写分离, 让like语句去从库查询

4.在数据库前端加上memcached服务器

5.用sphinx实现数据库的搜索, 因为like语句很难优化的

6.为搜索单独建集群, 实现每日读库计算搜索索引, 保存在服务器上提供搜索, 每5分钟给从库做一次增量 (此方法一般是大公司做的)

 

mysql优化

硬件优化

cpu

mem

disk

网卡

sql语句优化

1.索引优化

2.大的sql语句拆分成多个小的: 子查询  join连表查询

3.计算操作不要放在数据库里进行

4.搜索功能不要用数据库

架构优化

1.业务拆分: 比如搜索功能用sphinx, 某些业务应用使用nosql持久化存储

2.数据库前端加cache: memcached redis

3.数据静态化: 整个文件静态化, 页面片段静态化

4.数据库集群和读写分离

5.拆库拆表: 单表2000万等特别大的情况

 

软件优化

操作系统: x86_64

软件: mysql编译安装

my.cnf参数优化

优化的幅度很小

流程,制度,安全优化

详见下

 

 

制度与流程

1.项目开发

办公开发环境 --- 办公测试环境 --- IDC测试环境 --- IDC正式环境

2.数据库更新

开发人员提交需求 --- 开发主管审核 --- 部门领导审核 --- DBA审核 --- DBA执行 --- IDC执行

3.DBA参与项目数据库设计与审核

 

账户权限控制

1.需求不明确者让其知难而退

2.办公和测试环境可以放开权限, idc测试和正式环境要严格控制数据库写权限

3.开发人员正式环境数据库: 给单独的不对外服务的从库只读权限, 不能分配正式库(主库)的写权限

4.特殊人员(如领导)需要权限时, 要问清楚他做什么, 发邮件回复: 注明用户名,密码,权限范围, 多提醒他操作注意事项, 如果有可能由DBA人员代替其操作

5.特权账号由DBA控制

 

web账户权限分配

1.写库账户默认权限为: select, insert, update, delete, 不要给建表改表或all权限

2.读库账号默认权限为select(配合read-only参数)

3.专库专账号, 碎库特别多的小公司特别对待

4.如果是lamp一体, 在一台服务器的环境, db权限主要设置为localhost

5.www和db分离的, 可以根据web服务数量多少按ip或网段来授权

 

数据库客户端访问控制

1.更改默认mysql client端口

2.数据库web client端统一部署在1-2台不对外服务的server上, 限制ip及端口, 只能从办公室内网访问

3.不做公网域名解析, 用host或者内部ip实现访问

4.phpadmin站点目录独立于其他站点根目录, 只能由指定的域名或ip访问

5.限制使用web连接的账户来管理数据库, 根据用户角色设置指定账户访问

6.按开发及相关任意, 根据职位角色分配管理账户

7.设置指定账户访问(apache/nginx验证 + mysql用户 两个登录限制)

8.统一所有数据库账户登录入口地址, 禁止所有开发人员私自上传phpadmin等数据库管理的程序

9.开通VPN, 跳板机, 内部IP 来管理数据库

 

 

 

 

 

 

;