TXGLJ使用netflow监控网络流量

 按各地的ISP如各大运营商是要把流量发到TXGLJ进行JK的,具体手段就是运营商的交换机上配置netflow把监控的流量采集发送到TXGLJ要求的IP上,然后TXGLJ就可以进行流量分析了。

.交换机上配置下面归纳一下实施流量监控的步骤(以 Cisco 6000 系列交换机为例) : 1 )在 Cisco 6509 上配置 NetFlow (或其他网络设备),并输出到指定到 ossim 采集器( lp )的固定 UDP 端口。 2 )采集器软件为 ossim 系统的 F10W 一 tooll 具,该软件监听 UDP 端口,接收进入的 NetFlow 数据包并存储为特定格式。 3 )使用 Nfsen 等软件包中的工具对 NetFlow 源文件进行读取,转换成可读的 AS 1 Cll 格式,再用 ossim 内的 Perl 程序对 NetFlow 进行分析和规范格式的操作,并将读取的 NetFlow 信息存储入 Ossim 数据库中。 4 )依据蠕虫和。。 05 攻击等异常报文的流量特征,在分析程序中预设各种触发条件,定时运行,从中发现满足这些条件的「 low 。 5 )将分析结果在 Web 客户端中展示,或者通过


如果设奋不支持 Nettlow ,怎么对流量进行检测呢?对于这样的环境也有相应的解决方法,那就是使用 Fprobe 。利用 Fprobe 来生成 Netflow 报文,其默认格式为 VS 版本。最初「 probe 是一款在 BSO 环境下运行的软件,目前在 UNIX / Linux 平台上均可运行。它可以将 NIC 接口收到的数据转化为 Netflow 数据,并发送至 Netflow 分析端。我们可以通过部署这样一台 Ossim 服务器,将网络流量镜像至 Ossim 服务器,实现网络流量分析。 Ossim 服务器中的 Netflow 分析器,由下列三个工具组成:1 Fprobe :从远程主机发送数据流;2 Nfsen : NetFlow 的分析图形前端;3 Nfdump : NetFlow 采集模块;有关 Ossim 结构大家可以先参看本书第 14 章,这里介绍 Netflow 分析数据包的过程。首先,在网络接口接收网络数据,然后由「 probe 程序将收集的数据按照一定规则和格式进行转换 ( Netflow 格式),再发到系统的 555 端口(查看/ etc / d efa u It / fp 「 0 be 能得知详情),再由 Nfsen 系统中的 Nfdump 程序将转换后的数据统计

华为EPON OLT开局配置

配置思路:1. 登录olt(console进去之后配地址)2.配置上联口(配vlan和起三层地址互联路由的lan口)3.epon接分光器,分光器下接光猫4.自动发现光猫、配置DBA数据和线路模板5.注册光猫6.提交保存。  在 MA5680T上配置:

 telnet到MA5680T

 >>User name:root

>>User password:admin

 MA5680T>enable

MA5680T#config    

MA5680T(config)#sysname Ueusiuee_MA5680T   //修改系统名,根据实际设备修改 

Ueusiuee_MA5680T(config)# time 2010-07-15 09:00:11  //修改系统时间

Ueusiuee_MA5680T(config)# switch language-mode   //切换中文模式

  当前语言模式已切换到本地语种

 Ueusiuee_MA5680T(config)#display board  0 //查看所有单板状态

Ueusiuee_MA5680T(config)#board confirm 0      //确认所有单板 

 BaiZiMen_MA5680T(config)#interface epon 0/1  

BaiZiMen_MA5680T(config-if-epon-0/1)#port 0 ont-auto-find enable   //开启0端口的自动发现

BaiZiMen_MA5680T(config-if-epon-0/1)#port 1 ont-auto-find enable   //开启1端口的自动发现

 BaiZiMen_MA5680T(config-if-epon-0/1)#display ont autofind  0        //查看0端口发现的onu

Ueusiuee_MA5680T(config)#vlan 39 smart          //创建网管vlan 39  类型为smart

Ueusiuee_MA5680T(config)#port vlan 39 0/18 0        //透传vlan 到上行口

Ueusiuee_MA5680T(config)# vlan 2064 to 2095 smart   //创建从vlan号2094到2095的smart类型的宽带业务vlan

Ueusiuee_MA5680T(config)# vlan 3304 smart    //创建窄带语音vlan

Ueusiuee_MA5680T(config)# port vlan 3304 0/18 0    //透传窄带语音vlan

Ueusiuee_MA5680T(config)# port vlan 2064 to 2095 0/18 0

Ueusiuee_MA5680T(config)#interface vlanif  39     

Ueusiuee_MA5680T(config-vlanif39)# ip address 192.18.33.125 255.255.255.0        //配置网管地址

Ueusiuee_MA5680T(config)#quit

Ueusiuee_MA5680T(config)#ip route-static 0.0.0.0 0.0.0.0 192.18.33.254          //配置默认路由,172.18.33.254为网关

配置DBA模板和线路模板:

BaiZiMen_MA5680T(config)#display DBA-profile all   //查看所有创建过的dba模板

BaiZiMen_MA5680T(config)#DBA-profile add profile-id 13 profile-name MA5616 type3 assure 102400  max  15360 // 创建模板id为13; 模板名为MA5616;

Assure: 保证带宽10M ;  max:最大带宽15M;

BaiZiMen_MA5680T(config)#display ont-lineprofile epon all    //查看所有创建过的线路模板

BaiZiMen_MA5680T(config)#ont-lineprofile epon profile-id 13 profile-name 5616  //创建线路模板 

BaiZiMen_MA5680T(config-epon-lineprofile-13)#llid dba-profile-id 13   //线路模板中绑定dba模板ID为13的dba模板

BaiZiMen_MA5680T(config-epon-lineprofile-13)#commit //保存模板(此处必须保存否则将丢失模板配置)

BaiZiMen_MA5680T(config-epon-lineprofile-13)#quit

注册onu

BaiZiMen_MA5680T(config)#display  ont autofind  all                       

   ————————————————————————–  

   序列号          : 1                                                         

   框/槽/端口      : 0/1/0                                                     

   ONT MAC         : 286E-D487-3BB2                                            

   密码            : 00000000000000000000000000000000                          

   生产厂商ID      : HWTC                                                       

   ONT型号         : MDU                                                       

   ONT软件版本     : V8R306C01B053                                             

   ONT硬件版本     : MA5616                                                     

   ONT自动发现时间 : 2010-12-03 16:47:51

BaiZiMen_MA5680T(config-if-epon-0/1)#display ont autofind  0    //查看0端口发现的onu

BaiZiMen_MA5680T(config-if-epon-0/1)#ont add 0 0 mac-auth  286E-D487-3BB2   snmp ont-lineprofile-id 13 desc TO:JinHaiAnQingChuanLou_MA5616   // 注册端口为0 ;onu编号为0 ;  mac地址为0018-82B3-A4D7的onu ;   管理方式为snmp;    线路模板为13 ; desc:描述此onu所处位置以及设备型号

BAIZIMEN_MA5680T(config-if-gpon-0/1)#  ont ipconfig 0 0 ip-address 172.18.39.5 mask 255.255.255.0  gateway 192.18.39.1 manage-vlan 39  //给onu   0下发ip地址

BaiZiMen_MA5680T(config-if-gpon-0/1)# quit

配置业务虚接口:

service-port  vlan 39 epon 0/1/0 ont 0 multi-service user-vlan 39 tag-transform translate   //配置管理的业务虚接口

service-port  vlan 3304 epon 0/1/0 ont 0 multi-service user-vlan 3304 tag-transform translate  //配置语音的业务虚接口

service-port  vlan 2064 epon 0/1/0 ont 0 multi-service user-vlan 2064 tag-transform translate     //配置宽带的业务虚接口

……

service-port  vlan 2095 epon 0/1/0 ont 0 multi-service user-vlan 2095 tag-transform translate     //配置宽带业务虚接口

保存数据:

Ueusiuee_MA5680T(config)#save  (必须保存,否则设备重启后数据会丢失)

此为有管理的配置,如果私人的OLT不用snmp,那就

ont add 0 0 mac-auth  286E-D487-3BB2 oam ont- lineprofile-id 10 ont-

H3C交换机配置

买了个H3C的万M交换机,先一直跑不上万M,进端口后强制 万M才能跑起来

speed 10000 强制万M,

undo speed 取消

然后,可以用qos命令对端口限速

qos apply polixcy 7400M outbound 限速下午

qos apply polixcy 7400M inbound 限速上行

undo qos apply polixcy 7400M inbound 取消限速上行

其它命令:

display cu 查看当前配置

sys 进入系统视图

shutsdown 关闭端口

undo shutsdown 开启端口

一个硬盘上双系统安装

用PE,如老毛桃,可以直接在硬盘的不同分区安装不同的WIN11,

但在启动界面会有显示两个一样的win10 pro

如果找不到启动文件又想改变启动时显示的系统名字,可以

WIN+R,输入cmd,在窗口中输入cd /,目的在于打开根目录,然后再输入bcdedit

会显示所有的启动项目,

标识符<default>和<current>分别代表默认系统和当前系统

你可以根据标识符来修改显示的系统名字,如:

bcdedit /set {default} description “aaaa – WIN10”

bcdedit /set {current} description “aaaa – WIN7”

也可下载工具easybcd来修改

什么是云原生?容器,docker-compose和k8s区别

我们先从云计算说起。在云计算普及之前,一个应用想要发布到互联网,就需要企业自己先买几台服务器,找一个IDC机房,租几个机架,把服务器放进去。接下来就是装Linux系统,部署应用。我们就假定用Java写了Web应用,怎么部署上去呢?先配置Tomcat服务器,在把编译好的war包上传到服务器,有用FTP的,安全意识高一点的会选SCP,然后配置Nginx、MySQL这些服务,最后一通调试,把应用跑起来,就算齐活。

这种物理机配合自搭网络环境、自搭Linux、自配环境的方式,有很多缺点,但最主要的问题有这么几个:

  1. 扩容和维护难,因为是物理机,需要先采购后跑机房,遇到双十一业务量猛增是来不及扩容的,用行话讲就是计算资源缺乏弹性;
  2. 安全性太差,熟悉Linux的运维工程师本来就少,精通SELinux的更是凤毛麟角,而且,系统安全性仅仅是一个方面,应用部署的权限、流程造成的安全漏洞更大;
  3. 部署流程不规范,开发、测试和运维脱节,缺少自动化测试和部署,无法快速迭代业务。

解决方案是上云。上云不能解决所有问题,但部分解决了前两个问题:

  1. 云服务商提供的是虚拟机,比起物理机,虚拟机的创建、维护、销毁比物理机简单了太多,且随时可以扩容,很大程度上解决了“弹性计算”的问题,至于弹性程度有多大,还得看应用的架构和设计水平;
  2. 和绝大多数中小企业相比,云服务商在网络和服务器安全方面要强若干个数量级。只要选择合适的官方镜像,配合防火墙规则,系统级别的安全问题大大减少,可以将重点放到应用本身的安全性上。

但是如果仅仅满足上云,把物理机换成虚拟机,把物理网换成虚拟专用网(VPC),是远远不够的。这些是计算资源和网络资源层面的简化。应用方面,如果延续旧的一套开发、测试、部署流程,做不到快速迭代。

要做到快速迭代,敏捷开发,就需要DevOps,即开发运维由一个团队负责,开发阶段,就要把部署、运维的工作考虑进去,而不是发布一个war包或者jar包后扔给运维不管了。

重开发、轻部署,直接后果就是缺少自动化发布流程。想要把部署规范化,就需要整体考虑一系列问题。

还是以Java应用为例,如果是手动部署,那么就上传war包到服务器,覆盖原有的版本,重启Tomcat,再测试。如果发现有严重问题要回滚怎么办?把老版本再传一遍,然后重启Tomcat。

手动部署,每次部署都是一次生死考验,所以最好不要安排在半夜,以免手抖敲错了命令,本来中断10分钟的服务,变成了灾备恢复,中断3天。

稍微靠谱一点的是写脚本部署,但各家写出来的脚本都有各家特色,不通用,不易维护,所以更好的方式是用成熟的部署方案,比如Ansible,把脚本标准化,比如做成蓝绿发布,把服务器分组,比如A、B两组,先把流量切到B组,升级A组服务器,有问题就回滚,没问题了,再把流量切到A组,升级B组服务器,最后,恢复正常流量,整个部署完成。

但是回滚这个事情,远没有那么简单。做过开发的同学都知道,升级新版本,一般要加配置,改配置,如果回滚到旧版本,忘了把配置改回去,那旧版本可能也不能正常工作。

上云,除了物理变虚拟,简化运维外,最重要的特点——弹性计算,一定要充分利用。

理论指导实践,实践完善理论。如果我们分析大多数基于互联网的应用,可以看到,一个应用,通常用到的资源如下:

  1. 存储资源,通常对应着一个或多个数据库,例如MySQL、Oracle、PostgreSQL等;
  2. 计算资源,以Java应用为例,就是一个或多个Web应用,跑在Tomcat,或者通过SpringBoot自带嵌入式服务器;
  3. 网关,通常是Nginx之类的服务器,对外作为统一的服务入口,对内提供反向代理;
  4. 其他支撑业务的组件,例如,为提升应用性能采用的Redis集群作为缓存,应用内部各组件通信使用的消息系统如Kafka等,以及随着业务不断扩大增加的ES集群、日志分析和处理的集群等。

上云后,云服务商通常都提供托管的数据库,以及大规模存储系统(S3),可解决存储资源问题。通过云服务商提供的负载均衡(Load Balancer),也无需自行部署Nginx等网关,免去了运维的问题。各种标准的业务组件如Redis、Kafka等,均可直接租用云服务商提供的资源。

我们重点讨论计算资源,也就是云上的虚拟机资源。对于应用来说,可以设计成有状态和无状态两种。一个应用在一台虚拟机内跑着,如果有本地文件的修改,它就是有状态的。有状态的应用既不利于扩展,也不利于部署。反过来,如果一个应用在运行期数据总是存在数据库或者缓存集群,本地文件无任何修改,它就是无状态的。

无状态的应用对应的虚拟机实际上就是不变的计算资源。这里的“不变”非常重要,它是指,一台虚拟机通过一个固定的镜像(预先内置好必要的支持环境,如JRE等)启动后,部署一个应用(对应一个war包或者jar包),该虚拟机状态就不再变化了,直接运行到销毁。

有的同学会问:如果给这台虚拟机重新部署一个新的应用版本,它的状态不就发生了变化?

确实如此。为了确保虚拟机的不变性,一旦启动后部署了某个版本,就不允许再重新部署。这样一来,对虚拟机这种计算资源来说,就具有了不变性。不变性意味着某个虚拟机上的应用版本是确定的,与之打包的配置文件是确定的,不存在今天是版本1,明天变成版本2,后天回滚到版本1的情况。

计算资源不变,能确保启动一台虚拟机,对应发布的应用版本和配置是确定的且不变的,对于运维、排错非常重要。

那么如何在保持计算资源不变的前提下发布新版本?

我们以AWS的CodeDeploy服务为例,假设一组正在运行的某应用v1集群包含3台虚拟机:

   ┌─────────────────────────────────────┐
   │                 VPC                 │
   │           ┌────────────────────────┐│
   │           │      Target Group      ││
┌──┴──┐        │┌──────┐┌──────┐┌──────┐││
│ ELB │───────▶││EC2:v1││EC2:v1││EC2:v1│││
└──┬──┘        │└──────┘└──────┘└──────┘││
   │           └────────────────────────┘│
   └─────────────────────────────────────┘

现在,我们要把应用从v1升级到v2,绝不能直接把现有的3台虚拟机的应用直接升级,而是由CodeDeploy服务启动3台新的一模一样的虚拟机,只是部署的应用是v2。现在,一共有6台虚拟机,其中3台运行v1版本,另外3台运行v2版本,但此刻负载均衡控制的网络流量仍然导向v1集群,用户感受不到任何变化:

   ┌─────────────────────────────────────┐
   │                 VPC                 │
   │           ┌────────────────────────┐│
   │           │      Target Group      ││
┌──┴──┐        │┌──────┐┌──────┐┌──────┐││
│ ELB │───────▶││EC2:v1││EC2:v1││EC2:v1│││
└──┬──┘        │└──────┘└──────┘└──────┘││
   │           └────────────────────────┘│
   │           ┌────────────────────────┐│
   │           │      Target Group      ││
   │           │┌──────┐┌──────┐┌──────┐││
   │           ││EC2:v2││EC2:v2││EC2:v2│││
   │           │└──────┘└──────┘└──────┘││
   │           └────────────────────────┘│
   └─────────────────────────────────────┘

v2集群部署成功后,做一些自动化冒烟测试和内网测试,如果有问题,直接销毁,相当于本次部署失败,但无需回滚。如果没有问题,通过负载均衡把流量从v1集群切到v2,用户可无感知地直接访问v2版本:

   ┌─────────────────────────────────────┐
   │                 VPC                 │
   │           ┌────────────────────────┐│
   │           │      Target Group      ││
┌──┴──┐        │┌──────┐┌──────┐┌──────┐││
│ ELB │───┐    ││EC2:v1││EC2:v1││EC2:v1│││
└──┬──┘   │    │└──────┘└──────┘└──────┘││
   │      │    └────────────────────────┘│
   │      │    ┌────────────────────────┐│
   │      │    │      Target Group      ││
   │      │    │┌──────┐┌──────┐┌──────┐││
   │      └───▶││EC2:v2││EC2:v2││EC2:v2│││
   │           │└──────┘└──────┘└──────┘││
   │           └────────────────────────┘│
   └─────────────────────────────────────┘

稳定一段时间(例如15分钟)后,销毁v1集群。至此,整个升级完成。

上述的蓝绿部署就是CodeDeploy的一种标准部署流程。CodeDeploy也支持灰度发布,适用于更大规模的应用。

把计算资源不可变应用到部署上,实际上是充分利用了弹性计算这个优势,短时间创建和销毁虚拟机,只有上云才能做到,并且针对云计算,把部署流程变得更加简单可靠,每天发几个版本甚至几十、几百个版本都变得可能,DevOps能落地,有点“云原生”的味道了。

说到AWS的CodeDeploy,最早我使用AWS时,对于它的计费采用Reserved Instance预付模型感到很不理解,租用一台虚拟机,按国内阿里云、腾讯云包年包月预付享折扣不是更直观吗?如果仅仅把上云变成租用虚拟机,那就完全丧失了弹性计算的优势,相当于租用了一台虚拟机在里面自己折腾。AWS的Reserved Instance计费并不绑定某一台虚拟机,而是一种规格的虚拟机。我们还是举例说明,如果我们有1台2v4G规格的虚拟机,并购买了1年的Reserved Instance,那么,我随时可以销毁这台虚拟机,并重新创建一台同样规格的新的虚拟机,Reserved Instance计费会自动匹配到新的虚拟机上,这样才能实现计算资源不变,频繁实施蓝绿部署,真正把部署变成一种云服务。最近阿里云终于推出了节省计划的付费模式,有点真正的云计算的付费味道了,但是腾讯云、华为云还停留在包年包月和按量付费这两种原始租赁模型。

讲了这么多自动化部署,实际上一个指导思想就是如何充分利用云的弹性计算资源。从充分利用云的弹性资源为出发点,设计一整套开发、部署、测试的流程,就是云原生。弹性资源利用得越充分,云原生的“浓度”就越高,就越容易实施小步快跑的快速迭代。

那么虚拟机是不是弹性最好的计算资源呢?从应用的角度看,显然容器是一种比虚拟机更具弹性,更加抽象,也更容易部署的计算资源。

容器和虚拟机相比,它实际上是一种资源隔离的进程,运行在容器中的应用比独占一个虚拟机消耗的资源更少,启动速度更快。此外,容器的镜像包含了完整的运行时环境,部署的时候,无需考虑任何额外的组件,比其他任何部署方式都简单。使用容器,开发部署流程就变成了开发,生成镜像,推送至Docker Hub或云服务商提供的Registry,直接启动容器,整个过程大大简化。

使用容器比使用CodeDeploy部署还要更加简单,因为CodeDeploy需要在虚拟机镜像中预置Agent,由于没有统一的发布标准,还需要配置CodeDeploy,告诉它去哪拉取最新版本,这又涉及到一系列权限配置。而容器作为标准的部署方案,连发布系统都以Registry对各个镜像版本进行了有效管理,所以部署非常简单。

容器作为一种弹性计算资源,也应遵循计算不变性,即不要给容器挂载可变的存储卷。一组不变的容器集群才能更容易地升级。容器的运行方式本身就遵循了不变性原则,因为通过一个镜像启动一个容器,在运行过程中,是不可能换一个镜像的。容器本身也强烈不建议应用写入数据到文件系统,因为重启后这些修改将全部丢失。

容器的启动和销毁非常容易,不过,容器的管理却并不简单。容器的管理涉及到创建、调度、弹性扩容、负载均衡、故障检测等等,Kubernetes作为事实上的容器编排标准平台,已经成为各个云服务商的标配。

如果要直接使用K8s,在云环境中首先要有一组虚拟机资源作为底层资源,然后搭建K8s环境,定义好容器编排并启动容器。云服务商几乎都提供托管的K8s服务,但直接管理K8s仍然需要非常熟悉K8s的工程师。

还有一种更简单的使用容器的方式,即完全将底层虚拟机和K8s托管给云服务商,企业客户只需关心如何部署容器,底层的K8s和虚拟机对企业不可见或者无需关心。AWS的Elastic Container和阿里云的弹性容器均为此类服务。对于中小规模的应用来说,计算资源直接使用容器,再配合云服务商提供的负载均衡,托管的数据库、消息系统、日志系统等组件服务,应该是目前最“云原生”的一种方案。

最后,我们总结一下云原生的特点:

所谓云原生,就是在上云的过程中,充分发挥云平台的弹性计算、弹性存储的优势,尽量把应用设计成适合云计算的架构,把部署设计成简单易用的流程,这样才能实现业务快速上线,快速迭代

云原生是一个大方向,在上云的过程中,逐步改造应用架构和部署流程,从手动往自动转,逐步增加计算资源的弹性,就能把云原生一步步落地。

云原生之所以解释不清楚,是因为云原生没有确切的定义,云原生一直在发展变化之中,解释权不归某个人或组织所有。

何谓云原生?

技术的变革,一定是思想先行,云原生是一种构建和运行应用程序的方法,是一套技术体系和方法论。云原生(CloudNative)是一个组合词,Cloud+Native。Cloud表示应用程序位于云中,而不是传统的数据中心;Native表示应用程序从设计之初即考虑到云的环境,原生为云而设计,在云上以最佳姿势运行,充分利用和发挥云平台的弹性+分布式优势。

Pivotal公司的Matt Stine于2013年首次提出云原生(CloudNative)的概念;2015年,云原生刚推广时,Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征:12因素、微服务、自敏捷架构、基于API协作、扛脆弱性;到了2017年,Matt Stine在接受InfoQ采访时又改了口风,将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质;而Pivotal最新官网对云原生概括为4个要点:DevOps+持续交付+微服务+容器

2015年云原生计算基金会(CNCF)成立,CNCF掺和进来后,最初把云原生定义为包括:容器化封装+自动化管理+面向微服务;到了2018年,CNCF又更新了云原生的定义,把服务网格(Service Mesh)和声明式API给加了进来。

可见,不同的人和组织对云原生有不同的定义,相同的人和组织在不同时间点对云原生也有不同的定义,真是乱的一匹,搞得鄙人非常晕菜,我的应对很简单,选一个我最容易记住和理解的定义:DevOps+持续交付+微服务+容器。

总而言之,符合云原生架构的应用程序应该是:采用开源堆栈(K8S+Docker)进行容器化,基于微服务架构提高灵活性和可维护性,借助敏捷方法、DevOps支持持续迭代和运维自动化,利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

容器入门:Docker、Pod初探

01容器是什么?

– 容器是一种计算单元

作为一种计算单元,容器与线程、进程、虚拟机、物理机一样(如下图所示)。在连续尺度上,越往左隔离性、安全性和开销越低,越往右则越高。而容器则恰恰是介于进程和虚拟机之间的一种计算单元。

但并非所有的应用都适合选择容器,开发者可以根据自己应用的特点和需求选择最适合的计算单元。例如,你的应用是高性能、互信的,且处于同一个管理区域,那么用线程或者进程就可以满足;但如果你的应用是多租户的,并且和其他应用运行在同一个空间,那么你就需要考虑如何将这些应用安全地隔离开,使得数据不会被泄露或性能受到影响。那么这时,容器也许就是一个不错的选择了。

因为容器是一个「高度隔离的进程」,它在一般进程的隔离基础上又增加了新的隔离机制,这些隔离机制是使用Linux的内核提供的,它包括一些命名空间(Name Spaces)和CGroup。命名空间可以分为网络、存储和计算三大类。其中,最为重要的是网络命名空间。它保证了容器的网络是独立于其他容器网络的。每个容器自己看到的文件系统和其他容器的是不共享的,每个容器只能看到自己的进程ID,而进程编号也是连续的。

而说到容器与虚拟机最大的区别,刘俊辉认为,相对于虚拟机,容器最大的特征是它没有自己独立的操作系统,而是共享其宿主机上的一个操作系统;而虚拟机则运行在「一台独立的服务器上」。因此,容器相比于虚拟机的成本会小,但隔离性却有所欠缺。

– 容器是一种应用的包装形式

有过应用开发经验的人都知道,应用并不是一个单一的可执行文件,一个稍微复杂一点的应用包括多个部分,包括:代码、可执行文件、配置依赖、外部依赖(动态链接库)等。

所以在应用发行包装的时候,需要考虑目标操作系统的版本、系统架构以及它所依赖的模块等因素。否则应用安装时会改动系统的不同部分。

而容器作为一个应用的包装,它最大的特点就是实现了应用的独立和便携,容器本身包含了应用所有的依赖,这使得它可以再任意的基础设施上运行,不会因为系统版本、架构的问题,而导致各种意外。

02Docker是什么?

简单来说,Docker可以看作是一个非常成功的容器管理平台。Docker最重要的部分就是它的运行管理环境

正如上面所说,容器是一个计算单元,那么Docker的运行环境就是用来创建、管理和销毁这些计算单元的。在创建和管理这些计算单元的时候,需要用到计算单元的包装(也就是它的软件发行包),这些包装以容器镜像的方式存放在它的运行环境中,所有的容器计算单元都是通过这些镜像来创建的。

但镜像本身会有版本的发布、升级等需求,这就涉及到Docker的另一个重要组成部分DockerHub了。DockerHub有点像苹果的App Store,它是一个非常大的「容器市场」,所有常用的软件都可以在DockerHub上找到。

最后一个Docker的重要模块,就是用户界面和管理工具,它们用来向容器的运行环境发布命令或查看状态。只需要用一个Docker的命令加上一些参数,就可以实现创建、删除、查看容器的运行情况等操作。

接下来我们就来看看Docker的实际操作情况,我们会以运行一个Hello World的容器为例,讲讲Docker的使用情况。其实,只需要安装好Docker就可以尝试运行这个Hello World的容器了。

通过下面代码,我们来看看Docker做了些什么:

首先我们看到Docker在本地要去找Hello World最新版本的镜像,它发现本地并没有这个镜像后去DockerHub上把这个镜像给下载了下来。然后,这个镜像就被运行了,之后Docker后台就创建了这样一个容器。

Docker的出现,让容器应用管理变得非常轻松,运行容器只需要一个命令就可以实现。而从DockerHub上下载镜像、创建各种各样的隔离环境、创建容器与外部的网络通信环境都可以由Docker来完成。可以说Docker可以管理容器的整个生命周期。

Pod,一种增强型容器

Pod是一种组合的多容器运行单元,也是Kubernetes里的一个基础单元。你可以把它看作是一种容器的扩展或者增强型的容器。Pod里面包括一个主容器和数个辅助容器,它们共同完成一个特定的功能。把多个进程(容器也是一种隔离的进程)打包在一个Name Space里的时候,就构成了一个Pod。Pod里面不同进程的应用包装仍然是独立的(每个容器都会有自己的镜像)。

Pod的意义在于,它可以既保持主容器和辅助容器的的密切关系,又保持主容器的独立性。由于主容器和辅助容器的生命周期相同,可以同时被创建和销毁,因此把它们放在一个Pod中,可以使他们的交互更加高效。

而另一方面,主容器需要完成一些主要的工作,而另一些工作可能是有共性的,就可以单独打包由辅助容器来运行。

在K8S里,编排调度的最小单位并不是容器,而是Pod。有了Docker容器,为什么还需要一个Pod? 前面我们说Docker容器就好比云计算操作系统中的应用,K8S相当于操作系统,那Pod就是进程组:即Pod是对一组容器(一个或多个)的抽象。之所以做这样一层抽象,是因为在 Borg 项目的开发和实践过程中,Google 公司的工程师们发现,他们部署的应用,往往都存在着类似于“进程和进程组”的关系。在同一个Pod中,可以直接通过localhost通信,并且可以共享网络栈和Volume

非常推荐大家去一个叫Katacoda的网站,它上面有大量免费的在线实验,包括Docker及Docker Image等动手操作项目,而且现在是完全免费的。大家不妨去这里动手实操起来。

docker-compose

Dockerfile可以让用户管理一个单独的应用容器,而compose则允许用户在一个模板(yaml格式)中定义一组相关联的应用容器(被称为一个project,即项目)
例如一个web服务再加上后端的数据库服务容器等

为什么要使用docker-compose
使用一个Dockerfile模板文件,可以让用户很方便的定义一个单独应用容器。在工作中,经常会碰到需要多个容器相互配合来完成某项任务的情况,例如要实现一个web项目,除了web服务容器本身,往往还需要再加上后端的数据库服务容器,甚至还包括负载均衡容器等。
compose允许用户通过一个单独docker-compose.yml模板文件(YAML格式)来定义一组相关联的应用容器为一个项目(project)

docker-compose项目由python编写,调用docker服务提供的API来对容器进行管理,因此, 只要所操作的平台支持docker-API,就可以在其上利用conpose来进行编排管理。
简单来说:就是来管理多个容器的,定义启动顺序的,合理编排,方便管理。

docker-compose和k8s的区别

Docker Compose是一个基于Docker的单主机容器编排工具.适合开发、测试和暂存环境

而k8s是一个跨主机的集群部署工具,是大型生产级部署的更好选择

网络排查工具MTR

常用的 ping,tracert,nslookup 一般用来判断主机的网络连通性,其实 Linux 下有一个更好用的网络联通性判断工具,它可以结合ping nslookup tracert 来判断网络的相关特性,这个命令就是 mtr。mtr 全称 my traceroute,是一个把 ping 和 traceroute 合并到一个程序的网络诊断工具。

traceroute默认使用UDP数据包探测,而mtr默认使用ICMP报文探测,ICMP在某些路由节点的优先级要比其他数据包低,所以测试得到的数据可能低于实际情况, 参数 -U 使用UDP数据包探测 。

安装方法

1.Windows系统可以直接在https://cdn.ipip.net/17mon/besttrace.exe下载BestTrace工具并安装。也可以在https://github.com/oott123/WinMTR/releases GitHub上下载MTR专用工具,该工具为免安装,下载后可以直接使用。

2.Linux可以直接运行命令进行安装。

1.# Debian/Ubuntu 系统
2.apt install mtr
3.
4.# RedHat/CentOS 系统
5.yum install mtr

3.Apple客户端可以在App store搜索Best NetTools下载安装

4.Android客户端:可以在Google Play上下载TracePing,但是由于国内Google Play无法访问,笔者自行下载下来,可以直接访问 https://dwz.cn/KCdNPH4c 下载TracePing。

使用

MTR使用非常简单,查看本机到 http://qq.com 的路由以及连接情况直接运行如下命令:

1.mtr qq.com

MTR http://qq.com 测试界面

具体输出的参数含义为:

  • 第一列是IP地址
  • 丢包率:Loss
  • 已发送的包数:Snt
  • 最后一个包的延时:Last
  • 平均延时:Avg
  • 最低延时:Best
  • 最差延时:Wrst
  • 方差(稳定性):StDev

参数说明

-r or –report

使用 mtr -r http://qq.com 来打印报告,如果不使用 -r or –report 参数 mtr 会不断动态运行。使用 report 选项, mtr 会向 http://qq.com 主机发送 10 个 ICMP 包,然后直接输出结果。通常情况下 mtr 需要几秒钟时间来输出报告。mtr 报告由一系列跳数组成,每一跳意味着数据包通过节点或者路由器来达到目的主机。

一般情况下 mtr 前几跳都是本地 ISP,后几跳属于服务商比如 腾讯数据中心,中间跳数则是中间节点,如果发现前几跳异常,需要联系本地 ISP 服务提供上,相反如果后几跳出现问题,则需要联系服务提供商,中间几跳出现问题,则需要联系运营商进行处理

默认使用 -r 参数来生成报告,只会发送10个数据包,如果想要自定义数据包数量,可以使用 -c 参数

-s or –packetsize

使用 -s 来指定ping数据包的大小

1.mtr -s 100 qq.com

100 bytes 数据包会用来发送,测试,如果设置为负数,则每一次发送的数据包的大小都会是一个随机数。

-c

指定发送数量

1.mtr -c 100 qq.com

-n

不进行主机解释

使用 -n 选项来让 mtr 只输出 IP,而不对主机 host name 进行解释

1.mtr -n qq.com

MTR结果分析

当我们分析 MTR 报告时候,最好找出每一跳的任何问题。除了可以查看两个服务器之间的路径之外,MTR 在它的七列数据中提供了很多有价值的数据统计报告。Loss% 列展示了数据包在每一跳的丢失率。Snt 列记录的多少个数据包被送出。使用 –report 参数默认会送出10个数据包。如果使用 –report-cycles=[number-of-packets] 选项,MTR 就会按照 [number-of-packets] 指定的数量发出 ICMP 数据包。

Last, Avg, Best 和 Wrst 列都标识数据包往返的时间,使用的是毫秒( ms )单位表示。Last 表示最后一个数据包所用的时间, Avg 表示评价时间, Best 和 Wrst 表示最小和最大时间。在大多数情况下,平均时间( Avg)列需要我们特别注意。

最后一列 StDev 提供了数据包在每个主机的标准偏差。如果标准偏差越高,说明数据包在这个节点的延时越不相同。标准偏差会让您了解到平均延时是否是真的延时时间的中心点,或者测量数据受到某些问题的干扰。

例如,如果标准偏差很大,说明数据包的延迟是不确定的。一些数据包延迟很小(例如:25ms),另一些数据包延迟很大(例如:350ms)。当10个数据包全部发出后,得到的平均延迟可能是正常的,但是平均延迟是不能很好的反应实际情况的。如果标准偏差很高,使用最好和最坏的延迟来确定平均延迟是一个较好的方案。

在大多数情况下,您可以把 MTR 的输出分成三大块。根据配置,第二或第三跳一般都是您的本地 ISP,倒数第二或第三跳一般为您目的主机的ISP。中间的节点是数据包经过的路由器。

当分析 MTR 的输出时,您需要注意两点:loss 和 latency。

网络丢包

如果在任何一跳上看到 loss 的百分比,这就说明这一跳上可能有问题了。当然,很多服务提供商人为限制 ICMP 发送的速率,这也会导致此问题。那么如何才能指定是人为的限制 ICMP 传输 还是确定有丢包的现象?此时需要查看下一跳。如果下一跳没有丢包现象,说明上一条是人为限制的。如下示例:

人为限制MTR丢包

在此例中,第4跳发生了丢包现象,但是接下来几条都没任何丢包现象,说明第二跳的丢包是人为限制的。如果在接下来的几条中都有丢包,那就可能是第二跳有问题了。请记住,ICMP 包的速率限制和丢失可能会同时发生。

MTR丢包截图

从上面的图中,您可以看从第13跳和第17跳都有 10% 的丢包率,从接下来的几跳都有丢包现象,但是最后15,16跳都是100%的丢包率,我们可以猜测到100%的丢包率除了网络糟糕的原因之前还有人为限制 ICMP。所以,当我们看到不同的丢包率时,通常要以最后几跳为准

还有很多时候问题是在数据包返回途中发生的。数据包可以成功的到达目的主机,但是返回过程中遇到“困难”了。所以,当问题发生后,我们通常需要收集反方向的 MTR 报告。

此外,互联网设施的维护或短暂的网络拥挤可能会带来短暂的丢包率,当出现短暂的10%丢包率时候,不必担心,应用层的程序会弥补这点损失。

网络延迟

除了可以通过MTR报告查看丢包率,我们也还可以看到本地到目的之间的时延。因为是不通的位置,延迟通常会随着条数的增加而增加。所以,延迟通常取决于节点之间的物理距离和线路质量。

MTR查看网络延迟

从上面的MTR报告截图中,我们可以看到从第11跳到12跳的延迟猛增,直接导致了后面的延迟也很大,一般有可能是11跳到12跳属于不通地域,物理距离导致时延猛增,也有可能是第12条的路由器配置不当,或者是线路拥塞。需要具体问题进行具体的分析。

然而,高延迟并不一定意味着当前路由器有问题。延迟很大的原因也有可能是在返回过程中引发的。从这份报告的截图看不到返回的路径,返回的路径可能是完全不同的线路,所以一般需要进行双向MTR测试。

注:ICMP 速率限制也可能会增加延迟,但是一般可以查看最后一条的时间延迟来判断是否是上述情况。

根据MTR结果解决网络问题

MTR 报告显示的路由问题大都是暂时性的。很多问题在24小时内都被解决了。大多数情况下,如果您发现了路由问题,ISP 提供商已经监视到并且正在解决中了。当您经历网络问题后,可以选择提醒您的 ISP 提供商。当联系您的提供商时,需要发送一下 MTR 报告和相关的数据。没有有用的数据,提供商是没有办法去解决问题的。

然而大多数情况下,路由问题是比较少见的。比较常见的是因为物理距离太长,或者上网高峰,导致网络变的很慢。尤其是跨越大西洋和太平洋的时候,网络有时候会变的很慢。这种情况下,建议就近接入客户的节点。

centos网络命令

在CentOS系统上,目前有NetworkManager和network两种网络管理工具。如果两种都配置会引起冲突,而且NetworkManager在网络断开的时候,会清理路由,如果一些自定义的路由,没有加入到NetworkManager的配置文件中,路由就被清理掉,网络连接后需要自定义添加上去。

目前在CentOS上的NetworkManager版本比较低,而且比较适合有桌面环境的系统,所以服务器上保留network服务即可,将NetworkManager关闭,并且禁止开机启动。

systemd管理上:

systemctl status NetworkManager #查看状态

systemctl stop NetworkManager

systemctl disable NetworkManager #enable 表示开机自启 disable 表示开启不启动

如果NetworkManager没有运行,则可以通过简单运行来启动它。

# systemctl start NetworkManager

停止NetworkManager

要出于某种原因停止或停用NetworkManager,请发出以下命令。

# systemctl stop NetworkManager

启用NetworkManager后我们可以用以下图形命令来配置网络

nmtui

ifconfig -a 查处网络情况

查看网关和路由表(路由就是选路)
命令:route

跟踪数据包的转发路径
命令:traceroute

查看网络连接状态
命令:netstat
选项: -t tcp
-u udp
-p 进程
-a 所有
-n 数字形式显示

重启网络服务的方法
service network restart

ifconfig eth0 up (启用网卡) 或者ifup eth0

ifconfig eth0 down (禁用网卡) 或者 ifdown eth0

	同一个网络接口可以使用子接口的方式设置多个IP地址
	[root@centos ~]#  ifconfig eno33554984:2 192.168.146.152 netmask 255.255.255.0 up

	当服务器重启或网络服务重启后,子接口配置将消失,如需重启后依然生效,可以将配置子接口命令加入开机自动执行文件/etc/rc.local文件中。

(如果设置后还没有开机自动执行,是因为有的centos版本/etc/rc.d/rc.local没有执行权限,于是执行    chmod +x /etc/rc.d/rc.local就可以了)

以下看下如何配置网卡固定IP等

例如网卡设备名称为eth0, 用vi命令编辑网卡配置文件, 设置IP,掩码,网关,DNS。其中NAME和DEVICE 后面的名字按实际的网卡名字填写。

# cd /etc/sysconfig/network-scripts

然后ls 看到里面有网卡配置文件 ifcfg-eth0

# vi ifcfg-eth0

打开文件后按“i”键切换至编辑模式,修改以下相关内容,标颜色的部分按实际情况修改。编辑完成后,按”Esc”退出编辑模式,输入“: wq” 保存退出。

TYPE=Ethernet

DEVICE=eth0

NAME=eth0

BOOTPROTO=static

ONBOOT=yes

IPADDR=192.168.1.200

NETMASK=255.255.255.0

GATEWAY=192.168.1.1

DNS1=114.114.114.114

修改完成后重启网络服务

# systemctl restart network

Centos7中利用docker搭建openwrt旁路由

https://blog.csdn.net/ndd1996/article/details/109185747

1.查询当前网卡名称(以下均以网卡名eth0为例,请注意替换)

2.打开网卡混杂模式

3.创建虚拟网络

4.拉取openwrt镜像(以lean大神的openwrt为例)

拉取完毕之后查看一下拉取结果

5.创建并运行openwrt容器

6.查看openwrt容器运行状态,如果STATUS是UP则说明运行成功

7.进入openwrt容器

8.编辑配置文件

修改lan口内容

9.重启网络

docker中搭建openwrt到此结束,具体openwrt旁路由配置请参照百度或者google

CentOS7系统配置firewalld使用NAT方法将网络共享给内部局域网机器

1,用 Linux 打造路由器 zebra,

2,Linux系统下安装Vmware

3,linux+openwrt

4,firewalld+nat

5,iptables

自从用 HAProxy 对服务器做了负载均衡以后,感觉后端服务器真的没必要再配置并占用公网IP资源。
而且由于托管服务器的公网 IP 资源是固定的,想上 Keepalived 的话,需要挤出来 3 个公网 IP 使用,所以更加坚定了让负载均衡后端服务器释放公网 IP 的想法。
可是,后端服务器也不是简单释放公网 IP 就能正常工作的,正在运行的系统很多模块依然需要具有连接外网获取数据的能力。

所以就想到了用 CentOS 做一个软路由(内网 NAT 转发),如果能实现的话,就满足了我的需求。
搜索并试验了一番,目前发现用 iptables 是可行的,而且已经被我验证有效的方案。

由于用到了 iptables,需要停止并禁用内置的 firewalld 防火墙服务。

☼ 停止内置的 firewalld

systemctl stop firewalld
systemctl disable firewalld

☼ 打开系统的 IP 转发功能

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

☼ 安装 iptables 服务

yum -y install iptables-services
# 移除 iptables 服务
#yum -y remove iptables-services

☼ 查看 iptables 规则

iptables -L

☼ 清空默认的 filter 表

iptables -F

☼ 清空默认的 nat 表

iptables -t nat -F

☼ 默认规则,禁止所有入站,允许所有出站

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT

☼ 默认规则,允许所有本地环回通信,出入站

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

☼ 重点,开启 NAT 功能

iptables -t nat -A POSTROUTING -j MASQUERADE

☼ 完整的命令

可以在命令行下粘贴批量执行

systemctl stop firewalld
systemctl disable firewalld


yum -y install iptables-services


iptables -F
iptables -t nat -F
iptables -P INPUT  DROP
iptables -P OUTPUT ACCEPT
iptables -t nat -A POSTROUTING -j MASQUERADE

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp -s 192.168.66.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 你的可信任远程管理IP -j ACCEPT


iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

iptables-save > /etc/sysconfig/iptables
systemctl restart iptables



☼ 其他

# 允许已建立的传入连接
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 允许DHCP传入连接
iptables -A INPUT -i eth1 -p udp --dport 67:68 -j ACCEPT

# 默认禁止路由转发
iptables -P FORWARD DROP

# 允许内网路由转发
iptables -A FORWARD -s 192.168.66.0/24 -j ACCEPT

☼ 后记,补充 2017-12-13 20:28

捣鼓了一下午,NAT 转发当路由器供内网服务器上网终于搞定了,结果CentOS重启后,发现 iptables 的配置丢失,竟然没有永久保存?
太扯淡!

网上说这个问题的还很多,有人说可以制作自启动脚本,在启动时自动将 iptables 的规则重新注册一次,
也算是一个解决办法。

不过,思来想起,既然 CentOS 已经抛弃了 iptables ,那肯定是有一定道理的,firewalld 一定也有办法实现同样的功能吧!


firewall-cmd --permanent --zone=public --add-masquerade

# 调整防火墙策略,开放 vrrp 协议,给 Keepalived 使用
# 否则可能导致【脑裂】问题,争抢VIP,或者master挂掉之后backup无法正常工作
firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --in-interface ens33 --protocol vrrp -j ACCEPT
firewall-cmd --reload
#

搞定了。

当然其他功能端口的开放,这里就不啰嗦了 (0^0)。

other page1

环境介绍:

一台CentOS6 主机,双网卡,两网段

网口设定如下:

[root@CentOS ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=dhcp
[root@CentOS ~]# 

[root@CentOS ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static

IPADDR=192.168.66.1
NETMASK=255.255.255.0

[root@CentOS ~]# service network restart


[root@CentOS ~]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:0C:29:37:00:93  
          inet addr:172.16.20.183  Bcast:172.16.255.255  Mask:255.255.0.0

		  
eth1      Link encap:Ethernet  HWaddr 00:0C:29:37:00:9D  
          inet addr:192.168.66.1  Bcast:192.168.66.255  Mask:255.255.255.0		

打开网卡转发

[root@CentOS ~]# vim /etc/sysctl.conf  
net.ipv4.ip_forward = 1

立即生效

[root@CentOS ~]# sysctl -p

转发规则:

[root@CentOS ~]# iptables -t nat -A POSTROUTING -s 192.168.66.0/24 -j SNAT --to 172.16.20.183 #出口为静态IP选这个
[root@CentOS ~]# iptables -t nat -A POSTROUTING -s 192.168.66.0/24 -o eth0 -j MASQUERADE #出口为动态IP选这个

查看/保存转发规则

[root@CentOS ~]# iptables -t nat -nL
[root@CentOS ~]# service iptables save

other page2

学校实验室有台服务器申请了固定的公网IP,能连接外部网络,同时该机器和其它几台内部服务器连接在一个路由器上。需要将该服务器的网络共享给其它内网服务器。进行如下设置即可。

首先,外网服务器有两根网线连接,一根和外网相连,一根和内网路由器相连。在外网服务器进行NAT转发设置:

第一种方法:
开启NAT转发
# firewall-cmd --permanent --zone=public --add-masquerade
开放DNS使用的53端口,否则可能导致内网服务器虽然设置正确的DNS,但是依然无法进行域名解析。
# firewall-cmd --zone=public --add-port=53/tcp --permanent
重启防火墙
# systemctl restart firewalld.service
# 检查是否允许NAT转发
firewall-cmd --query-masquerade
# 关闭NAT转发
firewall-cmd --remove-masquerade

第二种方法:
开启ip_forward转发
在/etc/sysctl.conf配置文件尾部添加
net.ipv4.ip_forward=1
然后让其生效
# sysctl -p
执行firewalld命令进行转发:
firewall-cmd --permanent --direct --passthrough ipv4 -t nat -I POSTROUTING -o enoxxxxxx -j MASQUERADE -s 192.168.1.0/24
注意enoxxxxxx对应外网网口名称。
重启防火墙
# systemctl restart firewalld.service

设置外网服务器的IP地址为192.168.1.1,然后,在内网服务器中对配置文件/etc/sysconfig/network-scripts/ifcfg-enxxxxxx进行修改,设置网卡的网关为外网服务器的IP地址:

ONBOOT=yes
IPADDR=192.168.1.2
PREFIX=24
GATEWAY=192.168.1.1
DNS1=119.29.29.29

重启内网服务器的网络服务,即可访问外网了。

# systemctl restart network.service