Oby. Ale to "stary" news (z 27 marca?). Pokazuje się to cały czas na liście KB (trzeba "most recent" wybrać), ale sam dokument jest niedostępny.xal pisze:1.04
Cisco Nexus 1000v vs VMware vDS
Re: Cisco Nexus 1000v vs VMware vDS
Re: Cisco Nexus 1000v vs VMware vDS
Jest już 02.04, więc potwierdzam, że N1kv od vSphere 6.5U2 nie będzie działał lub jak zapowiadają ma nie działać.konradrz pisze:Oby. Ale to "stary" news (z 27 marca?). Pokazuje się to cały czas na liście KB (trzeba "most recent" wybrać), ale sam dokument jest niedostępny.xal pisze:1.04
Re: Cisco Nexus 1000v vs VMware vDS
Zły kierunek... historia pokazuje, że taki lock nie działa. Co było jak VMware wprowadził nowe licencjonowanie w 5-ce chyba? Zrobiła się niezła burza, a później oficjalny komunikat VMware "You speak, we listen" i nagle licencjonowanie się zmieniło. Teraz czuję będzie podobnie... W momencie jak wszyscy producenci zaczynają się otwierać, to VMware robi krok w tył... smutne to. Znam klientów, którzy zainwestowali grube setki tys zł w licencje N1K Adv, jestem ciekaw ich reakcji...gangrena pisze:Jest już 02.04, więc potwierdzam, że N1kv od vSphere 6.5U2 nie będzie działał lub jak zapowiadają ma nie działać.konradrz pisze:Oby. Ale to "stary" news (z 27 marca?). Pokazuje się to cały czas na liście KB (trzeba "most recent" wybrać), ale sam dokument jest niedostępny.xal pisze:1.04
Re: Cisco Nexus 1000v vs VMware vDS
Uwaga skupiła się na VSS oraz VDS. Tymczasem VMware inwestuje również w OVS (Open Virtual Switch) i wyraźnie wskazuje tę opcję jako możliwość migracji.xal pisze:Zły kierunek... historia pokazuje, że taki lock nie działa. Co było jak VMware wprowadził nowe licencjonowanie w 5-ce chyba? Zrobiła się niezła burza, a później oficjalny komunikat VMware "You speak, we listen" i nagle licencjonowanie się zmieniło. Teraz czuję będzie podobnie... W momencie jak wszyscy producenci zaczynają się otwierać, to VMware robi krok w tył... smutne to. Znam klientów, którzy zainwestowali grube setki tys zł w licencje N1K Adv, jestem ciekaw ich reakcji...
https://blogs.vmware.com/networkvirtual ... ODd7GWlraE
Zatem vendor lock-in jest pozorny. To jednak nie ta liga lock-in, co w przypadku ACI, gdzie jest twarde przywiązanie do konkretnego modelu urządzenia. Klient musi migrować do nowszej platformy, by mieć ten sam zestaw funkcjonalności i skalowalności.Moving forward, VMware will have a single virtual switch strategy that focuses on two sets of native virtual switch offerings – VMware vSphere® Standard Switch and vSphere Distributed Switch™ for VMware vSphere, and the Open virtual switch (OVS).
Cisco zaczęło mydlić oczy klientom, że jest w stanie zapewnić odpowiedni poziom supportu dla trybu AVS, który nie jest wspierany przez VMware. W efekcie powstało sporo przypadków ping-ponga między supportem producentów. To wymaga nakładów finansowych ze strony VMware, których Cisco dodatkowo ponosić nie chce. Od strony biznesowej nikt nie chciałby wspierać modelu, w którym nie ma przychodu, a są wydatki.
Od strony klienta każda inwestycja kiedyś się amortyzuje. Nie trzeba od razu przechodzić na vSphere 6.5U2. Grube setki tys. zł zamortyzują się, podobnie jak złotówki wydane na przełączniki fizyczne. Po tym czasie będzie można się zmigrować. Migracja w takim przypadku, to też nie rewolucja. Można na tych samych serwerach uruchomić kilka vswitchy i migrować aplikacje partiami.
Jak będzie? Zobaczymy. Mówienie, że VMware się zamyka nie jest zgodne z prawdą. Firma wspiera OVS, NSX-T KVM, jest edycja VMware Integrated Openstack, jest możliwość uruchamiania kontenerów zarówno na vSphere, jak i bez hypervisora. Jest natywna integracja z rozwiązaniami bezpieczeństwa, load-balancerami firm trzecich. Nie jest źle z tą otwartością.
Re: Cisco Nexus 1000v vs VMware vDS
Ale ja o ACI nic nie wspominałem Zaiste prawdą jest, że SDx zaczyna nam zmieniać rzeczywistość. Faktem jest też, że o blachach nie można zapominać. Owszem, część środowisk będzie można opędzić na dwóch przełącznikach z portami 100G (zakładam, że serwery prędzej czy później będą miały takie interfejsy) i wtedy można mówić, że underlay jest nieistotny. Przy bardziej złożonych środowiskach, integracja underlay z overlay i jednolita ich widzialność i programowalność ma wielkie zalety. Nic to, zobaczymy w którą stronę to pójdzie... Póki co u mnie na tapecie ansible i dockerygangrena pisze:...To jednak nie ta liga lock-in, co w przypadku ACI,...
Re: Cisco Nexus 1000v vs VMware vDS
Tak, nie wspominałeś, ale przytoczyłeś opinie, które nawet mocniej odnoszą się do platformy, którą wspierasz.xal pisze:Ale ja o ACI nic nie wspominałem
Urządzenia fizyczne jak najbardziej są potrzebne. Przepustowości w ASIC nikt teraz nie zastąpi. Tylko dzisiaj imho jest więcej korzyści z uruchomienia funkcjonalności na CPU/RAM, zamiast na ASIC/TCAM. Bardziej rozbudowane funkcjonalności sieciowe przesunięte bliżej aplikacji mają swoje zalety, które przeważają nad wadami. Nie wykluczam oczywiście, że trend się odwróci na bazie nowego podzespołu. Vide programowalne ASIC z Barefoot Networks.xal pisze:Zaiste prawdą jest, że SDx zaczyna nam zmieniać rzeczywistość. Faktem jest też, że o blachach nie można zapominać. Owszem, część środowisk będzie można opędzić na dwóch przełącznikach z portami 100G (zakładam, że serwery prędzej czy później będą miały takie interfejsy) i wtedy można mówić, że underlay jest nieistotny.
Moim zdaniem, argument jednolitej widzialności jest przerysowany. Warto to mieć, ale w Data Center nie jest to takie istotne. Gdzie to jest istotne? Dużo bardziej między Data Center, czyli w sieci core, gdzie są mniejsze przepustowości na dalszą odległość poprzez topologie non-ECMP. Operatorzy działają z siecią nakładkową naście lat na rynku bez integracji widoczności. Tymczasem najgłośniej argument jednolitej widzialności sieci overlay z underlay wypowiada producent, który do rozwiązania multi-pod stosuje EVPN z mcastami (bez zintegrowanej widoczności underlay), który nie ma widoczności ostatniej mili w Data Center (np. nie jest w stanie obserwować ruchu w ramach hosta), który dysponuje w zasadzie podstawowymi informacjami o sieci podkładowej dostępne również u innych producentów. Jeżeli się nie mylę ACI wciąż nie wspiera Netflow, choć nowy sprzęt jest Netflow capable i w trybie NX-OS można go użyć.xal pisze:Przy bardziej złożonych środowiskach, integracja underlay z overlay i jednolita ich widzialność i programowalność ma wielkie zalety. Nic to, zobaczymy w którą stronę to pójdzie... Póki co u mnie na tapecie ansible i dockery
Trzymam kciuki za ansible i dockery.
U mnie na tapecie workbook do CCIE SP i security w DC.
Re: Cisco Nexus 1000v vs VMware vDS
ACI bardzo dobrze działa z normalnym DVSem/vDSem (jaka jest obecna nomenklatura? , więc spokojnie można 1000v wy-amortyzować jak czas przyjdzie. AVS, o ile mi wiadomo, nigdy nie miał zbyt wielkiej "trakcji", właśnie ze względu na "partner support".gangrena pisze:Można na tych samych serwerach uruchomić kilka vswitchy i migrować aplikacje partiami.
No, chyba że i DVS/vDS API zostanie zablokowane "zewnętrznie", wtedy to totalny fakap. Bo -obecnie- OVS to nie to samo.
A, i jutro będę w pracy, to sprawdzę jak z tym Netflołem. Podobno od grudnia jest/miał być. Iiiii, nawet bez biura - wychodzi że jest.
Re: Cisco Nexus 1000v vs VMware vDS
Bawiłem się trochę pluginem ACI do DVS/VDS (nomenklatura przemienna;) i wygląda to lepiej, niż konfigurowanie EPG i kontraktów z natywnego GUI APIC-a. Jest jedno ale, nie ma synchronizacji między vCenter, a APIC-iem w sensie, jednoczesna konfiguracja spowoduje rozjazd lub nadpisanie ustawień.konradrz pisze:ACI bardzo dobrze działa z normalnym DVSem/vDSem (jaka jest obecna nomenklatura? , więc spokojnie można 1000v wy-amortyzować jak czas przyjdzie. AVS, o ile mi wiadomo, nigdy nie miał zbyt wielkiej "trakcji", właśnie ze względu na "partner support".
Zostało zapowiedziane usunięcie API do 3rd party vswitches. Czy to oznacza blokadę DVS dla ACI? Z tego, co wiem, to nie.konradrz pisze:No, chyba że i DVS/vDS API zostanie zablokowane "zewnętrznie", wtedy to totalny fakap. Bo -obecnie- OVS to nie to samo.
Dziękuję za info i link.konradrz pisze:A, i jutro będę w pracy, to sprawdzę jak z tym Netflołem. Podobno od grudnia jest/miał być. Iiiii, nawet bez biura - wychodzi że jest.
Re: Cisco Nexus 1000v vs VMware vDS
Tu to akurat dlatego, że "natywne" API do DVS/vDS nie ma opcji 'push' (w sensie, że jak kto co zmieni ręcznie, to jest notyfikacja do tzw event subscribera, w tym przykładzie APICa; te API akurat - o ile mi wiadomo - nie ma subscriberów wmontowanych, to dlatego).gangrena pisze:Jest jedno ale, nie ma synchronizacji między vCenter, a APIC-iem w sensie, jednoczesna konfiguracja spowoduje rozjazd lub nadpisanie ustawień.
Swoją drogą, dałoby się to rozwiązać odpytując API o obecny stan konfiguracji co sekundę/minutę/łotewer, ale to mogłoby spore obciążenie wygenerować (i dla pytacza, i dla odpytywanego). Pogadam, czy nie da się tego wprowadzić w jakiejś supermagicznej opcji.
Re: Cisco Nexus 1000v vs VMware vDS
Dochodzą mnie sluchy, ze handlowcy z VMWare przekonuja teraz klientów, ze integracja ACI z VMWare poprzez zezwalanie ACI na kontrolowanie DVS nie jest najlepszym pomysłem i zdecydowanie tego odradzaja. Niestety nie słyszałem jeszcze technicznych argumentów. Jest na to jakis techniczny argument, czy to po prostu strategia handlowa?
Re: Cisco Nexus 1000v vs VMware vDS
Ba, to nie "teraz" tylko od kiedy jest pomysł Cisco, by za pomocą ACI kontrolować DVS. Ba, to nie tylko handlowcy, ale i osoby techniczne.rack pisze:Dochodzą mnie sluchy, ze handlowcy z VMWare przekonuja teraz klientów, ze integracja ACI z VMWare poprzez zezwalanie ACI na kontrolowanie DVS nie jest najlepszym pomysłem i zdecydowanie tego odradzaja. Niestety nie słyszałem jeszcze technicznych argumentów. Jest na to jakis techniczny argument, czy to po prostu strategia handlowa?
Argument techniczny? Brak synchronizacji między tym, co dzieje się w ACI, a w vCenter. Można wydać sprzeczne instrukcje, które spowodują przerwy w działaniu aplikacji. Dział sieciowy i dział infrastruktury wirtualnej nie powinien odwoływać się do tych samych zasobów korzystając z różnych systemów, które między sobą nie kontrolują akcji. Poza tym przekonywanie klienta wynika też z tego, że ACI dla środowiska wirtualnego oferuje uboższy zakres funkcjonalności, niż NSX. Warto rozważyć po prostu rozwiązanie, które może być lepsze pod kątem wymagań środowiska wirtualnego lub mieszanego. Zatem jest to strategia handlowa, gdyż wiąże się ze sprzedażą, ale jest poparta konkretnymi argumentami technicznymi.
Re: Cisco Nexus 1000v vs VMware vDS
Brak synchronizacji między tym, co dzieje się w ACI, a w vCenter. Można wydać sprzeczne instrukcje, które spowodują przerwy w działaniu aplikacji.
- Nie do konca rozumiem. Konfiguracja VMM i EPG jest synchronizowana z VCenter. Które instrukcje mona wydac sprzecznie?
- A czy te dzialy nie powinny sie miedzy soba dogadac i ustalic wewnetrzna polityke ktora to ureguluje?Dział sieciowy i dział infrastruktury wirtualnej nie powinien odwoływać się do tych samych zasobów korzystając z różnych systemów, które między sobą nie kontrolują akcji.
- Tzn?Poza tym przekonywanie klienta wynika też z tego, że ACI dla środowiska wirtualnego oferuje uboższy zakres funkcjonalności, niż NSX.
Re: Cisco Nexus 1000v vs VMware vDS
Dostęp administracyjny jest w dwóch miejscach na raz, w ACI oraz w vCenter. To, co zostanie skonfigurowane w ACI, może być w konflikcie z tym, co akurat konfigurują osoby od wirtualizacji, czyli np. przypisanie VM-emek do port-grup, nadpisywanie ustawień port-grup. Oczywiście działy mogą się dogadać, ale po pierwsze nie zawsze jest to możliwe, a po drugie i tak zostawia to lukę bezpieczeństwa. Jeżeli jest zespół zajmujący się bezpieczeństwem, to powinien mieć on kontrolę od A do Z. Natomiast w przypadku ACI polegamy na zaufaniu, że osoba z wirtualizacji nie zrobi vmotion do innej strefy bezpieczeństwa. Powiesz, że jest attribute based EPG? Wszystkie te atrybuty administrator wirtualizacji może zmienić. Tak nie jest w przypadku NSX, gdzie Security Tag może zmienić tylko osoba z uprawnieniami sieciowymi.rack pisze: - Nie do konca rozumiem. Konfiguracja VMM i EPG jest synchronizowana z VCenter. Które instrukcje mona wydac sprzecznie?
Dodatkowo dochodzi ciągłość działania środowiska w przypadku utraty połączenia między APIC, a vCenter. Nie chodzi koniecznie o awarię tych komponentów, ale utratę połączenia. Wówczas w APIC nie można wykonać zmian - nie jest to problem. Gorzej, że APIC nie otrzyma już żadnych notyfikacji o migracjach VM-ek, czy zmian ustawień. W przypadku NSX migracje VM-ek, zachowanie dynamiki w Data Center, a nawet zmiany części ustawień są możliwe przy zachowaniu polityki bezpieczeństwa. W pełni się zgadzam, że takie sytuacje nie zdarzają się codziennie, ale jeżeli rozważamy ciągłość operacji, to jest to argument.
Powinnny. W mniejszych firmach nie jest to problem, w większych już tak.rack pisze: - A czy te dzialy nie powinny sie miedzy soba dogadac i ustalic wewnetrzna polityke ktora to ureguluje?
Tzn. choćby pod kątem security: ochrona East-West, Spoofguard, Identity FW, natywna integracja z rozwiązaniami bezpieczeństwa firm trzecich, optymalizacja przepływów, monitoring przepływów w obrębie hosta, bezagentowe skanowanie. Choćby pod kątem łączenia data center ze sobą: łatwiej można ustanowić połączenie przez sieć IP, można szyfrować ruch bez dodatkowych urządzeń, nie trzeba używać sieci nakładkowej. Pod kątem integracji z chmurą publiczną, komponenty sieciowe nie są przywiązane do sprzętu.rack pisze: - Tzn?
Re: Cisco Nexus 1000v vs VMware vDS
Gadu gadu ........ a za rok się dowiemy, że jedyna wspierana platforma sprzętowa pod VMware to DELL. Trzeba "zmonetyzować" zakup.
CCNA: R&S, Security, Wireless, Collaboration. MCSE: Cloud Platform and Infrastructure, Server Infrastructure. ITIL: Foundation. PPL(A)
https://www.facebook.com/itserviceskielce/ :: https://www.linkedin.com/company/itservicespoland :: https://www.linkedin.com/in/krzysztofkania/
https://www.facebook.com/itserviceskielce/ :: https://www.linkedin.com/company/itservicespoland :: https://www.linkedin.com/in/krzysztofkania/
Re: Cisco Nexus 1000v vs VMware vDS
Oby nie, ale fakt, wszystko jest możliwe.Kyniu pisze:Gadu gadu ........ a za rok się dowiemy, że jedyna wspierana platforma sprzętowa pod VMware to DELL. Trzeba "zmonetyzować" zakup.
Ubiłoby to całą strategię wokół hybrid cloud, więc byłoby to samobójstwo.