Laminar

thereisnospoon

0%

发表于 更新于 分类于

举个栗子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
my @items;
my @item;
my $stat_file = "/×××××/haproxy_stats.sock";
my $items_number;

sub get_haproxy_stat{
  # 获取状态类型的总数
  $items_number = `echo "show stat" | /usr/bin/socat $stat_file stdio|awk -F ',' 'NR==1 { print NF }'`;

  # 将每个类型的状态参数分别存储到数组变量items中
  for (my $i = 1; $i < $items_number; $i++){
    $_ = `echo "show stat" | /usr/bin/socat $stat_file stdio|awk -F ',' '!/^\$/ { print \$$i }'`;
    $items[$i-1] = $_;
  }

  # 遍历数组items，将其中的参数项处理并格式化打印
  foreach (@items){
    @item = split('\n', $_);
    foreach (@item){
      $_ =~ s/^$/-/g;
      if (@item[0] =~ /# /){
        my @first_line = split(" ", @item[0]);
        @item[0] = @first_line[-1];
      }
    }
    my $state_format = "  %-20s %-40s %-40s %-40s\n";
    printf($state_format, @item[0], @item[1], @item[2], @item[3]);
  }
}
阅读全文 »

发表于 更新于 分类于

Tacker - OpenStack NFV Orchestration

Tacker is an official OpenStack project building a Generic VNF Manager (VNFM) and a NFV Orchestrator (NFVO) to deploy and operate Network Services and Virtual Network Functions (VNFs) on an NFV infrastructure platform like OpenStack. It is based on ETSI MANO Architectural Framework and provides a functional stack to Orchestrate Network Services end-to-end using VNFs.

阅读全文 »

发表于 更新于 分类于

About NetScaler CPX

May 13, 2016

Citrix NetScaler CPX is a container-based application delivery controller that can be provisioned on a Docker host. NetScaler CPX enables customers to leverage Docker engine capabilities and use NetScaler load balancing and traffic management features for container-based applications. You can deploy one or more NetScaler CPX instances as standalone instances on a Docker host.

A NetScaler CPX instance provides throughput of up to 1 Gbps.

阅读全文 »

发表于 更新于 分类于

What is Mistral?

Mistral is a workflow service. Most business processes consist of multiple distinct interconnected steps that need to be executed in a particular order in a distributed environment. One can describe such process as a set of tasks and task relations and upload such description to Mistral so that it takes care of state management, correct execution order, parallelism, synchronization and high availability. Mistral also provides flexible task scheduling so that we can run a process according to a specified schedule (i.e. every Sunday at 4.00pm) instead of running it immediately. We call such set of tasks and relations between them a workflow.

阅读全文 »

发表于 更新于 分类于

架构

模块示意图


这里参考的是lbaasv2的driver，neutron_lbaas.conf中的service_provider即为lbaasv2的driver：
service_provider=LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default
neutron.conf中的service_plugins表示了lbaasv2的plugin：
lbaasv2 = neutron_lbaas.services.loadbalancer.plugin:LoadBalancerPluginv2

阅读全文 »

发表于 更新于 分类于

CGROUP

Cgroups是control groups的缩写，是Linux内核提供的一种可以限制、记录、隔离进程组（process groups）所使用的物理资源（如：cpu、memory、IO等等）的机制。最初由google的工程师提出，后来被整合进Linux内核。Cgroups也是LXC为实现虚拟化所使用的资源管理手段，可以说没有cgroups就没有LXC。

阅读全文 »

发表于 更新于 分类于

部署模式

API CELL

父cell，总的api入口，需要启动的openstack服务为keystone、neutron、glance（glance-api、glance-registry）、cinder（cinder-api）、nova（nova-api、nova-cells、nova-console、nova-consoleauth、nova-novncproxy）；需要启动的第三方服务为rabbit（rabbitmq-server）与mysql（mariadb）。

COMPUTE CELL

子cell，每一个子cell相当于一个独立的openstack环境，担负具体的计算功能。在子cell内可划分为控制节点与计算节点，控制节点上需要启动的openstack服务为neutron（neutron-openvswitch-agent）、cinder（cinder-scheduler、cinder-volume）、nova（nova-cells、nova-conductor、nova-scheduler、nova-compute）；控制节点上需要启动的第三方服务为rabbit（rabbitmq-server）与mysql（mariadb）；计算节点需要启动的openstack服务为neutron（neutron-openvswitch-agent）、nova（nova-compute）。（是否在子cell的控制节点上启用nova-compute为可选）

Cell的创建与删除

在父Cell上需要添加子Cell的信息

1
nova-manage cell create --name {子cell名称} --cell_type compute --username {子cell消息服务器用户名} --password {子cell消息服务器密码} --broker_hosts {子cell消息服务器地址，list形式} --hostname {子cell消息服务器地址} --port {子cell 消息服务器端口} --virtual_host {子cell消息服务器虚拟机主机地址}

在子Cell上需要添加父Cell的信息

1
nova-manage cell create --name <父cell名称> --cell_type api --username <父cell消息服务器用户名> --password <父cell消息服务器密码> --broker_hosts <父cell消息服务器地址，list形式> --hostname <父cell消息服务器地址> --port <父cell 消息服务器端口> --virtual_host {父cell消息服务器虚拟机主机地址}

删除Cell

1
nova-manage cell delete {cell_id}

请求的执行流程

当指令下发后，首先进入nova-api，经过对请求地址解析，参数处理之后，会调用到compute的api。非cell模式，compute的api为nova.compute.api.py；cell模式下，为nova.compute.cells_api.py。

父Cell到子Cell的过程

nova.compute.cells_api.py -> nova.cells.rpcapi.py -> nova.cells.manager.py -> nova.cells.messaging.py （以上为父Cell，主要功能为调度） -> nova.cells.messaging.py （子Cell，由此进入到具体的执行操作）

另一种调用的方式

nova.compute.cells_api.py （父Cell，调用其中的_cast_to_cells或_call_to_cells等方法，直接调用子Cell上nova.compute.api.py中的对应函数） -> nova.compute.api.py （子Cell）

相当于非Cell模式中的功能相简便移植到Cell模式中，只需要在nova.compute.cells_api.py中增加一个类似跳板的同名函数，并使用_cast_to_cells或_call_to_cells等方法将请求转到子Cell的nova.compute.api.py中的同名函数。

数据库与消息服务器

Cell模式下，有些函数访问的是自身的数据库且不向其他Cell的数据库同步数据；有些函数访问父Cell的数控库且会向其他Cell的数据库同步数据。原生的cell并不健全，如aggregate仅在父Cell上更新，并不同步数据到子Cell，而子Cell只从自己的数据库上查询，导致环境无法创建az。如遇到非Cell模式下可正常运行的功能在Cell模式下失效，可以查看是否存在数据读取的问题。

消息服务器的存活是Cell非常关心的一件事，在多个子Cell的环境中，其中一个子Cell的消息服务器挂了之后，会导致父Cell异常，需要尽快在父Cell的配置中删除异常的子Cell。