No VLAN support?
tomtheinfguy
3 Posts
April 26, 2018, 10:34 amQuote from tomtheinfguy on April 26, 2018, 10:34 amI have just read that I cannot break my physical interfaces up into VLAN's with PetaSAN and as such it dumps multiple different subnets on the same broadcast domain?
This is bad practice and extremely disappointing if it is the case!
In fact, its enough to make me not use PetaSAN at all.
Tom
I have just read that I cannot break my physical interfaces up into VLAN's with PetaSAN and as such it dumps multiple different subnets on the same broadcast domain?
This is bad practice and extremely disappointing if it is the case!
In fact, its enough to make me not use PetaSAN at all.
Tom
admin
2,930 Posts
April 26, 2018, 11:01 amQuote from admin on April 26, 2018, 11:01 amYes it is a shortcoming, we hope to support this. Note that it is best to have physically different networks for these subnets and not put them together (either in vlan or not) since this defeats the purpose of bandwidth segregation.
Yes it is a shortcoming, we hope to support this. Note that it is best to have physically different networks for these subnets and not put them together (either in vlan or not) since this defeats the purpose of bandwidth segregation.
tomtheinfguy
3 Posts
April 27, 2018, 7:20 amQuote from tomtheinfguy on April 27, 2018, 7:20 am
Quote from admin on April 26, 2018, 11:01 am
Yes it is a shortcoming, we hope to support this. Note that it is best to have physically different networks for these subnets and not put them together (either in vlan or not) since this defeats the purpose of bandwidth segregation.
I wouldn't say its a shortcoming, more of a major show stopper! You shouldn't 'hope to support it', but rather halt all other development efforts and implement VLAN support.
Multiple subnets within the same broadcast domain is just not the done thing, and VLAN's have been a fundamental part of networking for 15 years?
Quote from admin on April 26, 2018, 11:01 am
Yes it is a shortcoming, we hope to support this. Note that it is best to have physically different networks for these subnets and not put them together (either in vlan or not) since this defeats the purpose of bandwidth segregation.
I wouldn't say its a shortcoming, more of a major show stopper! You shouldn't 'hope to support it', but rather halt all other development efforts and implement VLAN support.
Multiple subnets within the same broadcast domain is just not the done thing, and VLAN's have been a fundamental part of networking for 15 years?
admin
2,930 Posts
April 27, 2018, 8:58 amQuote from admin on April 27, 2018, 8:58 amI agree with a lot of what you say, and as stated it will be supported. I do have some comments:
VLANs are ideal when you have different apps/clients sharing the same physical network, in PetaSAN case it is 1 app that needs/prefers to have different physical networks for itself and certainly not shared with other networks. It is best to treat PetaSAN as your backend storage layer beyond your hypervisor and keep the networks in between them dedicated for this.
The backend 1/Backend 2 subnets: these correspong to Ceph public and private networks, public is for client to Ceph io, whereas private for internal replication and recovery. The idea to split them is to put them on physically different networks so the recovery traffic does not share the same pipe with client traffic. Some (if not most) Ceph users just put them on 1 subnet (same subnet/lan/broadcast domain). PetaSAN prefers you put them on separate physical networks but if you choose to put them on the same network, client and recovery io traffic will be shared, it will not matter much if tag them with different vlans. iSCSI 1/2 : Again it is best for MPIO to have different physical networks.
I agree with a lot of what you say, and as stated it will be supported. I do have some comments:
VLANs are ideal when you have different apps/clients sharing the same physical network, in PetaSAN case it is 1 app that needs/prefers to have different physical networks for itself and certainly not shared with other networks. It is best to treat PetaSAN as your backend storage layer beyond your hypervisor and keep the networks in between them dedicated for this.
The backend 1/Backend 2 subnets: these correspong to Ceph public and private networks, public is for client to Ceph io, whereas private for internal replication and recovery. The idea to split them is to put them on physically different networks so the recovery traffic does not share the same pipe with client traffic. Some (if not most) Ceph users just put them on 1 subnet (same subnet/lan/broadcast domain). PetaSAN prefers you put them on separate physical networks but if you choose to put them on the same network, client and recovery io traffic will be shared, it will not matter much if tag them with different vlans. iSCSI 1/2 : Again it is best for MPIO to have different physical networks.
No VLAN support?
tomtheinfguy
3 Posts
Quote from tomtheinfguy on April 26, 2018, 10:34 amI have just read that I cannot break my physical interfaces up into VLAN's with PetaSAN and as such it dumps multiple different subnets on the same broadcast domain?
This is bad practice and extremely disappointing if it is the case!
In fact, its enough to make me not use PetaSAN at all.
Tom
I have just read that I cannot break my physical interfaces up into VLAN's with PetaSAN and as such it dumps multiple different subnets on the same broadcast domain?
This is bad practice and extremely disappointing if it is the case!
In fact, its enough to make me not use PetaSAN at all.
Tom
admin
2,930 Posts
Quote from admin on April 26, 2018, 11:01 amYes it is a shortcoming, we hope to support this. Note that it is best to have physically different networks for these subnets and not put them together (either in vlan or not) since this defeats the purpose of bandwidth segregation.
Yes it is a shortcoming, we hope to support this. Note that it is best to have physically different networks for these subnets and not put them together (either in vlan or not) since this defeats the purpose of bandwidth segregation.
tomtheinfguy
3 Posts
Quote from tomtheinfguy on April 27, 2018, 7:20 amQuote from admin on April 26, 2018, 11:01 amYes it is a shortcoming, we hope to support this. Note that it is best to have physically different networks for these subnets and not put them together (either in vlan or not) since this defeats the purpose of bandwidth segregation.
I wouldn't say its a shortcoming, more of a major show stopper! You shouldn't 'hope to support it', but rather halt all other development efforts and implement VLAN support.
Multiple subnets within the same broadcast domain is just not the done thing, and VLAN's have been a fundamental part of networking for 15 years?
Quote from admin on April 26, 2018, 11:01 amYes it is a shortcoming, we hope to support this. Note that it is best to have physically different networks for these subnets and not put them together (either in vlan or not) since this defeats the purpose of bandwidth segregation.
I wouldn't say its a shortcoming, more of a major show stopper! You shouldn't 'hope to support it', but rather halt all other development efforts and implement VLAN support.
Multiple subnets within the same broadcast domain is just not the done thing, and VLAN's have been a fundamental part of networking for 15 years?
admin
2,930 Posts
Quote from admin on April 27, 2018, 8:58 amI agree with a lot of what you say, and as stated it will be supported. I do have some comments:
VLANs are ideal when you have different apps/clients sharing the same physical network, in PetaSAN case it is 1 app that needs/prefers to have different physical networks for itself and certainly not shared with other networks. It is best to treat PetaSAN as your backend storage layer beyond your hypervisor and keep the networks in between them dedicated for this.
The backend 1/Backend 2 subnets: these correspong to Ceph public and private networks, public is for client to Ceph io, whereas private for internal replication and recovery. The idea to split them is to put them on physically different networks so the recovery traffic does not share the same pipe with client traffic. Some (if not most) Ceph users just put them on 1 subnet (same subnet/lan/broadcast domain). PetaSAN prefers you put them on separate physical networks but if you choose to put them on the same network, client and recovery io traffic will be shared, it will not matter much if tag them with different vlans. iSCSI 1/2 : Again it is best for MPIO to have different physical networks.
I agree with a lot of what you say, and as stated it will be supported. I do have some comments:
VLANs are ideal when you have different apps/clients sharing the same physical network, in PetaSAN case it is 1 app that needs/prefers to have different physical networks for itself and certainly not shared with other networks. It is best to treat PetaSAN as your backend storage layer beyond your hypervisor and keep the networks in between them dedicated for this.
The backend 1/Backend 2 subnets: these correspong to Ceph public and private networks, public is for client to Ceph io, whereas private for internal replication and recovery. The idea to split them is to put them on physically different networks so the recovery traffic does not share the same pipe with client traffic. Some (if not most) Ceph users just put them on 1 subnet (same subnet/lan/broadcast domain). PetaSAN prefers you put them on separate physical networks but if you choose to put them on the same network, client and recovery io traffic will be shared, it will not matter much if tag them with different vlans. iSCSI 1/2 : Again it is best for MPIO to have different physical networks.