Brainstorming about implications on the Network design when using Virtualisation

Europe/Zurich
31/2-029 (CERN)

31/2-029

CERN

8
Show room on map
Description
Luna had planned some time ago to have a survey of possible requirements from different communities in IT using or planning to use Virtual machines. He will present the first outcome.

Present: Andreas Hirstius, Harvard, Luna, Jan Michael, Alex I., Veronique L.,Xavier.

 

Luna Report: main points:

  1.  Luna talked to IS. As they are using a dedicated "service" = "cluster" = set of racks, they do not have any requirement regarding migration of VMs from one network to another.
  2. Reminder: the current network design in CC is such that there can be a maximum of 64 boxes (real or virtual) connected to one service. This number of 64 is arbitrary but is the current limit.
  3. We don't have enough PUBLIC IP addresses to go now to a very large scale usage of VM's
  4. If we increase the limit from 64 to 256, then, because of uniformity in all services, we would waste IP addresses (if they are not all used everywhere)
  5. It is a heavy intervention to increase the limit. It implies the re-IP of all systems in the affected service(s). 
  6.  ipV6 is NOT ready for production.
  7. Question from Luna: do the VM users need reloaction  ? and uniformity ? Anyway the number of IP addresses is limited.
  8. Andreas Hirstius thinks that we will run of the order of 10K VM's in the future. Xavier says that CMS is already using VM's. He will tell us who it is exactly (INFN)
  9. Do we need "PUBLIC" addresses for VM's ?
  10. Use-case: moving a VM from 1 Service to another: what is the required time for update. The upper limit probably depends on the service provided by the VM.
  11. Only migration of VM within the same network service is realistic. But this implies that we have here the network switch as a single point of failure.
  12. Andreas H.: VPN is a solution for high reliability:
    1. but we need one gateway per subnet = 'concentrator', for redundancy
    2. this is a solution for a limited number of boxes, not for large clusters such as lxbatch
  13.   DDNS, TTL, propagation issue, not controlled by CERN outside of CERN, cache is default on SLC4
  14. Need of manpower and money for any change on the CC Network design

Actions for next meeting(s):

  1. Presentation of VPN by Andreas:
    1. What is it ?
    2. What are the advantages ?
    3. What about the INFN experience
    4. Invite a maximum of Netops persons for a maximum of feedback/exchange
  2. We need more inputs about requirements:
    1. So far only Andreas H. claims that we will need VM's at a very large scale.
    2. What about CMS experience ?
    3. What do the GRID people think ?
  3.  

 

There are minutes attached to this event. Show them.
The agenda of this meeting is empty