Hello, When there is a host evacuation, any instance using a “m” flavor (local storage) will rebuild as its file system resides on that local node that was lost. In general, under normal operation, we do not expect a host evacuation to happen (instead we expect live migration). However, this week Intel IT switched us from a /24 network to a /16; and from looking at the logs, it does appear that this change did cause a host evacuation.
Maybe I should revise my statement below to: If your instance requires changes to the filesystem other than cloud-init services (any manual changes to the file system) it should use a “v” flavor and a cinder-volume. I can provide training for this if the team believes it valuable. I should add: Tomorrow IT is installing five new servers into the rack for VMware. If the technician accidentally removed a management connection for a compute node on the switch, all the instances on the compute node will evacuate; and If your instance was on that compute node and you were using a “v” flavor with a volume, you would not notice, you would not even be logged out of an ssh session. But if your instance’s filesystem locally resided on that compute node with an “m” flavor, it will rebuild when it restarts on the next available compute. Br, - Stephen From: Kranthi Guttikonda [mailto:[email protected]] Sent: Thursday, October 05, 2017 08:24 To: Gooch, Stephen; [email protected] Subject: Re: [onap-discuss] Note on xlarge Ephemeral Storage on Integration POD Hi Stephen, Was there any rebuild happened? Looks like onap-daily-test-vm<http://10.12.25.2/project/instances/6f53efbd-b098-4dba-b6e2-a67d5e9e6a31/> was rebuilt. I have lost all the data in it including scripts. It uses m1.small Thanks, Kranthi From: <[email protected]<mailto:[email protected]>> on behalf of "Gooch, Stephen" <[email protected]<mailto:[email protected]>> Date: Wednesday, October 4, 2017 at 11:55 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [onap-discuss] Note on xlarge Ephemeral Storage on Integration POD Hello, VMs with xlarge ephemeral storage (flavors m1.xlarge, and m1.xxlarge), will rebuild under normal cluster maintenance. i.e., they do not support live migration when a compute node is taken offline. While we prefer all VMs to use volumes (non-ephemeral) storage for HA reasons in case of a compute node power loss (non-planed), images requiring more than 80GB of storage are highly recommended to use the v1 equivalent flavors & boot from a volume to avoid the rebuild even under planned maintenance. wrs_sgooch@pod-onap-01-vjhost:~$ nova flavor-list +--------------------------------------+------------+-----------+------+-----------+------+-------+-------------+-----------+ | ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | +--------------------------------------+------------+-----------+------+-----------+------+-------+-------------+-----------+ | 1534679b-8601-497e-bc73-500b6e435275 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True | | 19cc9887-d5a1-4045-9894-d9622ef6dbad | v3.large | 12288 | 0 | 0 | | 6 | 1.0 | True | | 1a0d1e0a-9e6d-4dfc-a0d8-73aa2ef794e6 | m1.small | 2048 | 20 | 0 | | 1 | 1.0 | True | | 214fb10f-5e3c-4ea7-b2e6-bb7e0623ac3d | v2.medium | 8192 | 0 | 0 | | 2 | 1.0 | True | | 292e1e03-9968-46a4-b788-fbf4cd1a647a | v1.xxlarge | 65536 | 0 | 0 | | 12 | 1.0 | True | | 5211b5d6-d006-4501-8e47-3136e4cf7668 | m1.tiny | 512 | 1 | 0 | | 1 | 1.0 | True | | 5c4d5b48-93a8-4654-b8d1-832ce618d5d4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True | | 764efb04-5a46-4806-a766-2bdd24559f39 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True | | 79927a49-0dc2-450d-ae01-0bf9b72c40c7 | v1.xlarge | 16384 | 0 | 0 | | 8 | 1.0 | True | | a5aba347-c74b-423b-b739-62ed8b45b800 | v2.xlarge | 24576 | 0 | 0 | | 12 | 1.0 | True | | b8571cc9-d615-4045-84d8-023fa4139d7b | v2.large | 8192 | 0 | 0 | | 8 | 1.0 | True | | f0c1f92f-3cb0-4903-ac18-f0aae20bd6ed | v1.medium | 4096 | 0 | 0 | | 2 | 1.0 | True | | f1db313b-609c-447a-9663-f0977b228174 | m1.xxlarge | 65536 | 160 | 0 | | 12 | 1.0 | True | | f41a9a52-e7df-4ade-a104-9591e46685d7 | v1.large | 8192 | 0 | 0 | | 4 | 1.0 | True | +--------------------------------------+------------+-----------+------+-----------+------+-------+-------------+-----------+ NOTE: There is currently no planned maintenance scheduled. Br, - Stephen Stephen Gooch | Senior Member of Technical Staff | Wind River +1.510.965.7909 , Skype ID: Stephen.gooch
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
