Presentation at the International Industry-Academia Workshop on Cloud Reliability and Resilience. 7-8 November 2016, Berlin, Germany.
Organized by EIT Digital and Huawei GRC, Germany.
Twitter: @CloudRR2016
Failures happen. Building resilient cloud infrastructure requires an end-to-end automated approach to failure remediation. This approach must go beyond the current DevOps model of monitoring the system and getting engineers alerted when a failure condition occurs.
Recently, event driven automation and workflows re-emerged as a way to automate troubleshooting, remediation, and a variety of Day-2 operations. Facebook famously uses FBAR to "save 16,000 engineer-hours, a day, in ops". Similar approaches had been reported by other hyper-scale cloud providers. Open-source auto-remediation platforms like StackStorm are replacing legacy Runbook automation products, and have been successfully used to automate applications, networks, security, and cloud infrastructure.
In this presentation we give a brief history of workflow automation, overview the common architecture ingredients of a typical event driven automation framework, compare and contrast alternative approaches to day-2 automation, and, most importantly, share real-world use cases and examples of applying event driven automation in operations.
Digitalisering og API-revolusjonen gjør at stadig flere snakker om API. Men når stadig flere snakker om en ting øker sannsynligheten for misforståelser. Så når du snakker om API, snakker du om det fra en forretnings-dimensjon, arkitektur-dimensjon eller teknologi-dimensjon? Og hva er egentlig forskjellen på disse?
Vor allem dank seinem robusten Arbeitsmarkt und seiner Vorbildrolle im Umweltschutz liegt Deutschland in puncto Zukunftsfähigkeit auf einem Spitzenplatz. Doch zunehmende Verteilungskonflikte und Schwächen bei der politischen Steuerungsfähigkeit trüben die Aussichten. Dies ergeben die Sustainable Governance Indicators (SGI), die die Regierungsführung in den OECD- und EU-Staaten bewerten.
Mehr zur Studie finden Sie hier: http://www.bertelsmann-stiftung.de/de/themen/aktuelle-meldungen/2016/august/sustainable-governance-indicators-2016/
Professor i juridik med särskild inriktning på offentlig upphandling vid University of East Anglia Law School. Kuznik är en av de främsta experterna på offentlig upphandling inom EU och har bland annat varit rådgivare åt OECD i frågan.
In grammars we trust: LeadMine, a knowledge driven solutionNextMove Software
We present a system employing large grammars and dictionaries to recognize a broad range of chemical entities. The system utilizes these re-sources to identify chemical entities without an explicit tokenization step. To al-low recognition of terms slightly outside the coverage of these resources we employ spelling correction, entity extension, and merging of adjacent entities. Recall is enhanced by the use of abbreviation detection and precision is en-hanced by the removal of abbreviations of non-entities. With the use of training data to produce further dictionaries of terms to recognize/ignore our system achieved 86.2% precision and 85.0% recall on an unused development set.
[db tech showcase Tokyo 2017] D21: ついに Red Hat Enterprise Linuxで SQL Serverが使...Insight Technology, Inc.
いよいよリリースが間近に迫ったSQL Server 2017 Linux版。SQL Serverの第一人者 Dr. Kこと熊澤 幸生がリリース版を待ちきれずにRed Hat Enterprise Linux上で検証してみました。
Windows版と Linux版で果たしてSQL Serverの処理性能に差があるのか?注目の検証結果をいち早くお知らせします。
NTT Docomo's Challenge looking ahead the world pf 5G × OpenStack - OpenStack最...VirtualTech Japan Inc.
タイトル:NTT Docomo's Challenge looking ahead the world pf 5G × OpenStack
アジェンダ:
- Current Challenge
-- DOCOMO Cloud Platform
-- BizDevOps
- Challenge for the future
-- DOCOMO 5G Open Cloud
-- Next Challenge
27. OpenStack-Ansibleで作るOpenStack HA環境 Mitaka版
日本仮想化技術 27
HAProxyを稼働させるホストを指定します。
今回はControllerサーバーにHAProxyをインストールする設定とします。
haproxy_hosts:
controller-01:
ip: 172.29.236.10
log_hostsセクション
各コンテナより出力されるsyslogを集約するコンテナです。
今回はControllerサーバーにコンテナを作成します。
log_hosts:
controller-01:
ip: 172.29.236.10
3.3 user_variables.ymlファイルの設定
本ファイルではOpenStack各コンポーネント(Glance、Nova、Apache等)のオプション設定を行
います。
以下のコマンドで設定ファイルを編集します。
controller$ sudo vi /etc/openstack_deploy/user_variables.yml
## Common Glance Overrides
# Set glance_default_store to "swift" if using Cloud Files or swift backend
# or "rbd" if using ceph backend; the latter will trigger ceph to get
# installed on glance. If using a file store, a shared file store is
# recommended. See the OpenStack-Ansible install guide and the OpenStack
# documentation for more details.
glance_default_store: file ← コメントアウトをはずす
3.4 user_secrets.ymlファイルの設定
user_secrets.yml ファイルでは、OpenStack内の各コンポーネントで使用する初期パスワードをま
とめています。
以下の操作を行い、user_secrets.yml ファイルにパスワードを生成します。
40. OpenStack-Ansibleで作るOpenStack HA環境 Mitaka版
日本仮想化技術 40
controller_utility_container# nova image-list
+--------------------------------------+---------------------+--------+--------+
| ID | Name | Status | Server |
+--------------------------------------+---------------------+--------+--------+
| 25751b89-15c5-4903-9135-4a93c66f112a | cirros-0.3.4-x86_64 | ACTIVE | |
+--------------------------------------+---------------------+--------+--------+
53. OpenStack-Ansibleで作るOpenStack HA環境 Mitaka版
日本仮想化技術 53
インスタンス一覧を表示し起動したインスタンスのIDを確認します。
controller_utility_container# nova list
+--------------------------------------+------+--------+------------+-------------
+------------------------+
| ID | Name | Status | Task State | Power State |
Networks |
+--------------------------------------+------+--------+------------+-------------
+------------------------+
| 05477352-6652-4087-9a93-7376e327d5cb | vm1 | ACTIVE | - | Running |
demo-net=192.168.100.3 |
+--------------------------------------+------+--------+------------+-------------
+------------------------+
Neutronのポート一覧より該当インスタンスで使用しているポートIDを検索します。
controller_utility_container# neutron port-list | grep 192.168.100.3
| c044267e-0902-4fff-9909-1b05d9204683 | | fa:16:3e:7d:49:92 | {"subnet_id":
"e95ff2a9-7500-4926-8692-5f27a06ca589", "ip_address": "192.168.100.3"} |
FloatingIPを作成します。
root@controller-01_utility_container# neutron floatingip-create ext-net
Created a new floatingip:
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| fixed_ip_address | |
| floating_ip_address | 172.16.100.6 |
| floating_network_id | 8ee3a91d-a516-4962-bbe4-ab8ecfcd92b2 |
| id | ab123966-87a1-401a-8c9c-b5b818a14d1b |
| port_id | |
| router_id | |
| status | DOWN |
| tenant_id | 81ce71826dd24dc7a39d59b54b9c21bf |
+---------------------+--------------------------------------+
FloatingIPの一覧を表示し、正しく作成されたかどうか確認します。
54. OpenStack-Ansibleで作るOpenStack HA環境 Mitaka版
日本仮想化技術 54
controller_utility_container# neutron floatingip-list
+--------------------------------------+------------------+---------------------+--
-------+
| id | fixed_ip_address | floating_ip_address |
port_id |
+--------------------------------------+------------------+---------------------+--
-------+
| ab123966-87a1-401a-8c9c-b5b818a14d1b | | 172.16.100.3 |
|
+--------------------------------------+------------------+---------------------+--
-------+
検索したポートへFloatingIPを割り当てます。
controller_utility_container# neutron floatingip-associate ab123966-87a1-401a-8c9c-
b5b818a14d1b c044267e-0902-4fff-9909-1b05d9204683
Associated floating IP ab123966-87a1-401a-8c9c-b5b818a14d1b
もう一度インスタンス一覧を表示し、FloatingIPが割り当てられたことを確認します。
controller_utility_container# nova list
+--------------------------------------+------+--------+------------+-------------
+--------------------------------------+
| ID | Name | Status | Task State | Power State |
Networks |
+--------------------------------------+------+--------+------------+-------------
+--------------------------------------+
| 05477352-6652-4087-9a93-7376e327d5cb | vm1 | ACTIVE | - | Running |
demo-net=192.168.100.3, 172.16.100.3 |
+--------------------------------------+------+--------+------------+-------------
+--------------------------------------+
6.9 Cinderの設定
以下コマンドでCinderボリュームを作成し、正常にCinderが動作していることを確認します。
以下の例では volume01 という名前でサイズ2GBのボリュームを作成します。
controller_utility_container# cinder create --display-name volume01 2
ボリュームが作成されていることを確認します。
55. OpenStack-Ansibleで作るOpenStack HA環境 Mitaka版
日本仮想化技術 55
controller_utility_container# cinder list
+--------------------------------------+-----------+--------------+------+---------
----+----------+-------------+
| ID | Status | Display Name | Size | Volume
Type | Bootable | Attached to |
+--------------------------------------+-----------+--------------+------+---------
----+----------+-------------+
| e28b625e-2239-4d89-a809-a0d98abaa505 | available | volume01 | 2 | None
| false | |
+--------------------------------------+-----------+--------------+------+---------
----+----------+-------------+
作成したボリュームをインスタンスに割り当てます。
controller_utility_container# nova volume-attach vm1 e28b625e-2239-4d89-a809-
a0d98abaa505
+----------+--------------------------------------+
| Property | Value |
+----------+--------------------------------------+
| device | /dev/vdb |
| id | e28b625e-2239-4d89-a809-a0d98abaa505 |
| serverId | 05477352-6652-4087-9a93-7376e327d5cb |
| volumeId | e28b625e-2239-4d89-a809-a0d98abaa505 |
+----------+--------------------------------------+
再びボリューム一覧を表示して、正しく割り当てられたことを確認します。
controller_utility_container# cinder list
+--------------------------------------+--------+--------------+------+------------
-+----------+--------------------------------------+
| ID | Status | Display Name | Size | Volume Type
| Bootable | Attached to |
+--------------------------------------+--------+--------------+------+------------
-+----------+--------------------------------------+
| e28b625e-2239-4d89-a809-a0d98abaa505 | in-use | volume01 | 2 | None
| false | 05477352-6652-4087-9a93-7376e327d5cb |
+--------------------------------------+--------+--------------+------+------------
-+----------+--------------------------------------+
6.10 インスタンスの動作確認
最後に、作成したインスタンスへSSHでログインし正しく動作するか確認します。
56. OpenStack-Ansibleで作るOpenStack HA環境 Mitaka版
日本仮想化技術 56
インスタンスへの疎通確認
ping [割り当てたFloatingIPアドレス]
SSHログイン
ssh cirros@[割り当てたFloatingIPアドレス]
cirros@172.16.100.3's password: ← パスワードは cubswin:)
割り当てたCinderボリュームにパーティションを作成
$ sudo fdisk /dev/vdb
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): ← そのままEnter
Using default value 1
First sector (2048-4194303, default 2048): ← そのままEnter
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-4194303, default 4194303): ← そのまま
Enter
Using default value 4194303
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
作成したパーティションをフォーマット
57. OpenStack-Ansibleで作るOpenStack HA環境 Mitaka版
日本仮想化技術 57
$ sudo mkfs /dev/vdb1
mke2fs 1.42.2 (27-Mar-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
131072 inodes, 524032 blocks
26201 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=536870912
16 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
作成したパーティションをマウント
$ sudo mount /dev/vdb1 /mnt
パーティションのサイズ確認
/mntへCinderボリュームがマウントされていることを確認します
$ df -h
Filesystem Size Used Available Use% Mounted on
/dev 242.3M 0 242.3M 0% /dev
/dev/vda1 23.2M 18.0M 4.0M 82% /
tmpfs 245.8M 0 245.8M 0% /dev/shm
tmpfs 200.0K 88.0K 112.0K 44% /run
/dev/vdb1 2.0G 3.0M 1.9G 0% /mnt
58. OpenStack-Ansibleで作るOpenStack HA環境 Mitaka版
日本仮想化技術 58
7. Tipsとトラブルシューティング
この章では、OpenStack-Anibleに関連するトラブルの回避方法について説明します。
7.1 コンテナを削除し再構築する
OpenStack-Ansibleでは、環境を一から構築しなおしたいときのために既存の環境を削除するスク
リプトが用意されています。
このスクリプトを実行すると /etc/openstack_deploy 配下で設定したファイルは残りますが、デプ
ロイ実施後に構築されたもの(コンテナやDB等)がすべて削除されます。必要に応じて実行前にバ
ックアップを取っておいてください。
controller# cd /opt/openstack-ansible/
controller# scripts/teardown.sh
-----------------------------------------------------------------------------
WARNING: This is a destructive action. All containers will be destroyed and
all data within the containers will be removed. Some data will be
removed from the host as well. /etc/openstack_deploy will be preserved
and may be manually removed if needed.
Please verify that you have backed up all important data prior to
proceeding with the teardown script.
-----------------------------------------------------------------------------
To REALLY destroy all containers and delete the data within them,
type 'Y' or 'y' and press enter:
7.2 OpenStack構築後Controllerサーバーを再起動すると正常に動作しな
い
Controllerサーバーを再起動するとコンテナの起動順等の理由によりGaleraクラスタ(DBサービス)が
正しく起動できないことがあります。
この場合、以下の手順でGaleraクラスタのリカバリーを実行してください。
controller# cd /opt/openstack_deploy/playbook
controller# openstack-ansible -e galera_ignore_cluster_state=true galera-
install.yml