Mitaka Openstack 排错备忘

问题1:

安装mitaka并安装F5 agent后,设置F5 agent的配置中tunnel类型为vxlan

在openstack中创建网络,并创建loadbalancer,发现在F5上自动创建的tunnel是gre的

修改 /etc/neutron/plugins/ml2/ml2_conf.ini  中的ML2段落下的租户网络类型为vxlan,发现依旧推送gre tunnel

tenant_network_types = vxlan

原因:

在创建网络的时候,tenant_network_types 配置项的第一个配置是gre,导致产生的租户网络类型是gre,这样即便后来修改了该配置,已经产生的类型依旧是gre,导致推送到F5上的tunnel始终是gre。

附,正常配置:

 

问题2:

如果通过openstack配置了一个loadbalancer,此后重启compute节点上的neutron-server,则系统提示必须先删除之前创建loadbalancer,否则启动失败

2017-01-13 18:55:38.297 24480 ERROR neutron_lbaas.services.loadbalancer.plugin [req-00e705df-f351-481a-853d-cc250a3b01a2 – – – – -] Delete associated load balancers before removing providers [u’f5networks’]

待解

docker 容器粗体验之:快速搭建 WordPress in containers

底层系统平台: CENTOS7

  1. yum update
  2. yum -sSL https://get.docker.com | sh 安装docker
  3. service start docker, chkconfig docker on
  4. docker pull mysql
  5. docker pull wordpress
  6. docker run –name wp-mysql -e MYSQL_ROOT_PASSWORD=abc123 -d mysql:latest
  7. docker run –name my-wp -e WORDPRESS_DB_PASSWORD=abc123 –link wp-mysql:mysql -p 80:80 -d wordpress

访问你底层系统的http://IP

wechatimg124

就是这么简单快。。。 当然只是感觉一下,还有太多要学的。。。。。。。

基于业务模板自动化配置F5

这是很早前写的一个样例,基于业务模板,系统自动化创建业务配置

业务输入模板(可以通过任何形式产生,例如一个自服务的portal website):

createvs.txt  createpool.txt createmonitor.txt

中间程序F5_Deploy.py, 中间输出 tmsh.txt (作为ssh.py的输入)

(如果系统支持iControlRest,可以直接利用Python执行REST)

自动执行ssh.py

 

 

Openstack Mitaka 在Centos7上的自动化安装

4.pic_hd1.虚机三个网卡, 网卡1 管理网络 host-only, 网卡2 可上网 public internet, 网卡3 openstack未来vm流量网络 host-only (本例中192.168.215.x是管理网络,192.168.214.x是vm流量网络)
2.安装Centos7 x86_64,安装两台,4G+内存,20G+硬盘
3.修改好主机名,安装时候设置好NTP,确保机器可以上网,只安装为 infrastructure server 不安装任何其他服务
4. yum install git
5. yum install centos-release-openstack-mitaka
6. yum -y install http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-7.noarch.rpm
7.yum -y upgrade
8. 修改/etc/sysctl.conf
net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0

9.安装ovs
yum -y install openvswitch
service openvswitch start
chkconfig openvswitch on

创建两个bridge
ovs-vsctl add-br br-int
ovs-vsctl add-br br-ex
10. 重启
=================所有设备都准备好后===============
11. cd /root/
12. git clone https://github.com/myf5/openstack-mitaka-installer-centos7.git
13. 在sample-config目录下有2个已经配好的安装文件, 将控制节点配置文件拷贝到控制节点的/root/openstack-mitaka-installer-centos7/configs/下,并命名为main-config.rc
将计算节点配置文件拷贝到计算节点的/root/openstack-mitaka-installer-centos7/configs/下,并命名为main-config.rc.
14. ./main-installer.sh install执行安装

更多细节说明请阅读  https://github.com/myf5/openstack-mitaka-installer-centos7 

完全安装启动后,再安装LBAASV2在dashboard上的显示:

参考 http://docs.openstack.org/draft/networking-guide/config-lbaas.html 中的

Add LBaaS panels to Dashboard 部分

FW:利用自定义MIB采集标准MIB中不存在的数据

SNMP (Simple Network Management Protocol) is an internet protocol used to monitor and manage devices including servers, routers, switches and assorted other devices. It allows gathering a glut of data – this can be hardware information (eg. cpu temperature), network information (eg. interface speed) or software information (eg. number of HTTP requests).

However, to get at this information, it first needs to be addressable. SNMP itself does not define which bits of information are available. Instead it uses MIBs, or Management Information Bases which are basically hierarchies or trees of OIDs or object identifiers. SNMP is implemented in numerous devices including the devices we use for load balancing and shaping our traffic.

To load balance our main internet presence we use BIG-IP LTMs from F5. By default, it comes with a rather extensive MIB but sometimes doesn’t have exactly what we want. It wasn’t until version 11.2.0 that F5 introduced the ability to add custom OIDs to the MIB. Even better is that it lets us run and capture the output of shell commands on the device itself. This functionality gives exactly what is needed to get some data that otherwise wouldn’t be automatically available. Without further ado, here is how to use this.

(Fair warning, doing this requires some knowledge of Tcl, but Tcl is a really easy language to pick up.)

First, some information about the OID structure

  • the base OID for F5s BIG-IP devices is .1.3.6.1.4.1.3375.2
  • custom OIDs are added with the .100 suffix (ie. .1.3.6.1.4.1.3375.2.100)

On startup, the SNMP daemon on the BIG-IP checks for a file called /config/snmp/custom_mib.tcl. This file contains the OID definitions and Tcl functions to be called when the OID is requested.

To add a new OID you first have to register it using the register_mib function

where oid is something like ".1", ".2", ".3.1", etc. tcl_function is the name of the function that you want to call. And finally the type of the OID being defined. There are four types supported: int, string, gauge, and counter.

Once we’ve registered a function, we need to then define that function. So further down in the file, section off a part of it for your custom functions.

For example:


 

It should be noted that the function will receive no arguments, so whatever processing needs to be done needs to be done without context.

It is recommended that any shell commands executed should be wrapped in a catch statement. This way the snmpd is protected slightly. Also, watch out for things like infinite loops or logic errors. Since the Tcl execution happens within the snmpd process, it is possible to do unhealthy things that can have an adverse impact on the daemon.

To pick up the changes to the custom_mib.tcl the SNMP daemon needs to be restarted (bigstart snmpd restart). And of course, the custom OID should be checked to make sure everything is working:

Remember to check the log file (/var/log/snmpd.log) for errors.

So while this functionality is interesting, it is much more interesting to see a practical application. The default F5 MIB does not include every bit of detail you might want – sometimes it is only retrievable via the interpreter/shell or even tmsh. So here is an example of harvesting the time in seconds since the last configuration update and making it available:

To get the time in seconds since the last configuration update, BASH can be used to call tmsh:

Unfortunately, this returns a string in which only a single field is needed. With a judicious use of cut the seconds can be extracted and stored. And since this information might be useful outside SNMP, it can be stored on the file system somewhere. To generate this file, putting this into the crontab works.

Now that the data is available in a file, all that is needed now is a simple Tcl function to return the data:


 

Now this data is available via SNMP. Specifically it is available for Nagios to monitor and large discrepancies between last update time between BIG-IP devices can be alerted. This is just the tip of the iceberg. With some more Tcl knowledge, more complex information can be made available via SNMP. Of course, this was just a quick hack and using cron and temporary files might not be suitable to all use cases, but this does demonstrate the ease and hackability of extending the default MIB of BIG-IP devices.

To read further on customizing MIB entries for BIG-IP devices, take a look at the F5 knowledge base article.

https://support.f5.com/kb/en-us/solutions/public/13000/500/sol13596.html