刚接触devstack，可能第一步发愁的就是写 local.conf 了吧。
反正我是在部署前为了让网络的连通性得到保障，根据实际环境在网络规划面前做了考虑。下面是网络方面的部分配置：

1
2
3
4
5

HOST_IP=192.168.100.15  #宿主机接口IP地址
FLOATING_RANGE="192.168.100.0/24"  #provide网络CIDR
PUBLIC_NETWORK_GATEWAY="192.168.100.1"  #provide网络网关
FIXED_RANGE="192.168.10.0/24"  #self-service网络CIDR
NETWORK_GATEWAY="192.168.10.1"  #self-service网络网关

今天老大说openstack的默认安全组会使ovs产生大量流表，需要优化。So，开始分析一波吧 —- 基于 Q 版 qs。

简介

由于 Open vSwitch 无法直接与 Linux iptables 进行交互，因此为了实现安全组，之前采用了在 br-int 与实例之间增加一个 Linux 网桥来实现基于 iptables 的安全组功能。通常情况下，实例与基础物理网络之间的附加组件越多，性能与可扩展性越低。为了缓解这一问题，Neutron OpenvSwitch Agent 中实现了基于 OVS 流表的安全组驱动，当然这个驱动是可选的。

方案概述

使用类似于“物理旁挂，逻辑串联”的方式旁挂在 qrouter 旁。
根据用户的需求，是否使用PBR将流量引入FW，需要则在qrouter的namespace写入iptables策略，不需要则删掉策略。
拓扑如下图所示：

简介

随着云计算的发展，安全方面得到越来越多的重视，但云安全这块领域应该才算刚起步，目前各个传统安全厂商将各自的安全产品云化也只是将镜像抠出来部署进云环境，然后使用传统的处理方式将流量引入安全设备进行处理。
本文主要讲述如何将 firewall 镜像引入 openstack 平台进行使用，firewall 以 360 镜像为例。

简介

为了弥补openstack当前环境中较为匮乏的安全解决方案，引入 360 的 csmp（也是一个openstack环境，内附各种安全设备镜像），通过在 underlay 进行引流回注完成对接，方案架构如下图所示：

Hello World