так домашняя хранилка или лаба? начнем с того, что минус за кликбейтный заголовок.
Дальше минусы кончились, но были бы - за несоотвествие темы содержимому; за много воды ни о чем; за затертые темы "я тут не смог сделать нормальный nas"; отдельный минус за слово сторадж (поясню, английское storage произносится как сторейдж)
так-то ipv6 teredo нельзя назвать "доступ за NAT", т.к. адрес вам выдается глобальный, маршрутизируемый в инторнетах и считай, что сервер выставлен голым задом в инторнет. Префикс 2001::/16 входит в блок 2000::/3, который и есть Global unicast. Просто teredo - это такой специальный способ выставить голый зад из приватного ipv4 в публичный ipv6.
два момента... 1) нафига вы пишите статью, суть которой - ссылка на 7и минутное видео? Читая статью на хабре я не хочу смотреть видео, я хочу именно читать.
2) суть всей домашней виртуализации - это найти железо. если ты намыл где-то сервант с 128Gb Ram и 32cpuCores, то всё остальное - это мелочи недостойные упоминания
если постоянно общаешься с драконами, то сам становишься драконом. Вот и тут типичный сотрудник HR проецирует свои взгляды но область в которой не разбирается. Поверьте, HR-проблемы (к слову, описаны довольно точно) лишь 10-20% от всех проблем тим-лида. Основные проблемы которые решает тим-лид - это взаимодействие команды с внешним миром и внутренние бурления в команде. И обе они - пропасть.
чем "отечественный РП" отличается от нормального PM - рассказано в этой статье. single point of contact? не, не слышали. Project scope definition - вы офанарели, я тут документацию не пишу, а контролирую! Еще попросите к боссам сходить, когда в проект пихают всякое, но без денег, сроков и людей... Составление плана проекта, нарисовать диграмму Ганта - да вы смеетесь, вы, что сами безрукие?! Предпроектные активности типа поиска ресурсов и оценки целесообразности - я должен за начальников работу работать?
самое прикольное в том, что не mininet ни k8s-netsim не позволят эмулировать действительные проблемы, их достаточно лишь для изучения каких-то минимальных начальных основ. Например, основные беды openFlow случаются в тот момент, когда сильно кастомный доработанный openVswitch, dpdk и свой контроллер - и ну никак ты их не разместишь на одном хосте, даже если вычислительных ресурсов хоста хватает. Или те же "сетевые топологии в k8s" - это не сеть про сеть, а про упоротый фланнель или сервис-меш )
у наших решений есть две проблемы - 1) отсутствие стандартизации вместо с велосипедостроением - в итоге cisco с juniper прекрасно строят ipsec, а вот S-Terra с VipNet - нет, хотя ГОСТ, который впрочем описывает только алгоритм... 2) все наши решения - это linux на x86, ну или в последнее время на arm. Ну то есть шифрование на процессоре общего назначения, который при этом еще и роутит и линукс на себе запущает... никаких гарантий времени шифрования/дешифрования, чтоб можно было выстроить простую и логичную обработку трафика
вы вообще понятия не имеете как работает tcp или веб-сервера. tcp именно дожидается того, что все нужные пакеты придут и более того, если пришли 1 и 3, а 2 не пришел еще и попросит отправить 2 еще раз. Есть такой механизм - selective acknowledgements.
Веб сервер не замрет от этого, потому что существуют неблокирующие операции чтения из сокетов и многопоточность.
Далее про кафку: продюсер устанавливает с брокером две tcp сессии - одну для метаданных, одну для сообщений. И если продюсер не будет принудительно у себя в недрах закрывать объект кафки (KafkaProducer.Close в python, например) после каждой отправки сообщения, то все сообщения будут ходить в рамках одной tcp-сессии и как бы там пакеты по сети не ходили петлями, если таки tcp-достижимость сохраняется (tcp-сессия не разорвалась) - то с одного продюсера сообщения попадут в топик именно в том порядке, в каком их отправлял продюсер.
стек tcp/ip гарантирует, что к ПРИЛОЖЕНИЮ-получателю данные придут в том же порядке, что и отправило ПРИЛОЖЕНИЕ-отправитель. пакеты-то по сети придут как им вздумается, но вот на уровне драйвера tcp они отлежатся, пока не соберутся как надо и уже на уровень приложения попадут как надо.
так себе... так, почему же фабрика все таки IP? В тексте нет ответа на этот вопрос.
Второе интересное место - отдельная сторейдж сеть - мотивация к ней тоже странная - "Это сделано для предотвращения пересечений клиентского трафика, чтобы виртуальные серверы не работали с дисками через интернет, а общались в изолированной сетевой плоскости SAN" - зачем? Изоляция ради изоляции может быть решена в рамках одного порта без лишнего дорогого оборудования. Нет ни слова про qos, loseless ethernet и чуствительность трафика систем хранения к потерям.
кластер - это несколько узлов выполняющих одну задачу. бывают кластеры для повышения производительности общей системы (hadoop), кластер для повышения емкости (кластер гипервизоров), так и кластеры для повышения отказоустойчивости (failover cluster, например у Cisco ASA или MS Failover Cluster).
по поводу балансеров: балансер служит для двух целей - обеспечение бесперебойной работы того что он там балансирует и соответственно сам не должен становиться точкой отказа; распределение нагрузки. Ни nginx, ни haproxy не умеют ничего самостоятельно про второй пункт. А еще ngnix про себя сам думать ничего не может, потому что он F5 ;)
ах, да - кто это сказал, что они best-in-class? хоть кто-то из софтовых решений умеет в аппаратное ускорение шифрования, например?
ну то есть вы предлагаете вместо того чтоб взять просто squid засесть за пересборку или вообще за программирование? ну так в принципе и хлеб напильником можно резать, да )
nginx и haproxy - НЕ балансировщики ) это reverse proxy. например, из важных функций балансировщика у nginx и haproxy нет возможности кластеризации, т.е. обеспечения отказоустойчивости - надо городить что-то с помщью другого софта типа keepalived, pacemaker и т.п.
F5 LTM, Citrix NetScaler, Kemp - это балансировщики.
что-то, мне кажется, вы сильно не понимаете, что такое прокси.
есть forward proxy: это софтина перенаправляет запросы от пользователей к серверам в интернет. То есть, в браузере у пользователя вы явно настраиваете адрес прокси (ни или curl -x) и браузер идет к проксе и говорит "дай мне страничку", а прокси устанавливает новое соединения, возможно с другого интерфейса, получает страничку и перекладывает ее в пользовательское соединение. Это - 3proxy, squid, tinyproxy, etc...
есть reverse proxy который ставится в обратную сторону. Это по сути обычный веб-сервер принимающий запросы от пользователей из интернета и перенапавляющий их другим веб-серверам. Это - nginx, haproxy, traefik, apache, etc.
вы в своей задаче в посте описываете обычный каскадированный forward proxy и продукт берете соответствующий. А в комментах вам советуют reverse proxy и вы пишите - пробую, интересно, но ничего не выходит. И не выйдет: ngnix и haproxy - это reverse proxy, они для другого. У forward proxy и reverse proxy (web server, по-факту) даже формат get запроса разный:
так домашняя хранилка или лаба? начнем с того, что минус за кликбейтный заголовок.
Дальше минусы кончились, но были бы - за несоотвествие темы содержимому; за много воды ни о чем; за затертые темы "я тут не смог сделать нормальный nas"; отдельный минус за слово сторадж (поясню, английское storage произносится как сторейдж)
ну если без свитча, то зачем морочиться ethernet-ом? Две карточки infiniband на озоне стоят ~12тыр, кабель еще 3. Будет 40g )
так-то ipv6 teredo нельзя назвать "доступ за NAT", т.к. адрес вам выдается глобальный, маршрутизируемый в инторнетах и считай, что сервер выставлен голым задом в инторнет. Префикс 2001::/16 входит в блок 2000::/3, который и есть Global unicast. Просто teredo - это такой специальный способ выставить голый зад из приватного ipv4 в публичный ipv6.
два момента... 1) нафига вы пишите статью, суть которой - ссылка на 7и минутное видео? Читая статью на хабре я не хочу смотреть видео, я хочу именно читать.
2) суть всей домашней виртуализации - это найти железо. если ты намыл где-то сервант с 128Gb Ram и 32cpuCores, то всё остальное - это мелочи недостойные упоминания
если постоянно общаешься с драконами, то сам становишься драконом. Вот и тут типичный сотрудник HR проецирует свои взгляды но область в которой не разбирается. Поверьте, HR-проблемы (к слову, описаны довольно точно) лишь 10-20% от всех проблем тим-лида. Основные проблемы которые решает тим-лид - это взаимодействие команды с внешним миром и внутренние бурления в команде. И обе они - пропасть.
чем "отечественный РП" отличается от нормального PM - рассказано в этой статье. single point of contact? не, не слышали. Project scope definition - вы офанарели, я тут документацию не пишу, а контролирую! Еще попросите к боссам сходить, когда в проект пихают всякое, но без денег, сроков и людей... Составление плана проекта, нарисовать диграмму Ганта - да вы смеетесь, вы, что сами безрукие?! Предпроектные активности типа поиска ресурсов и оценки целесообразности - я должен за начальников работу работать?
самое прикольное в том, что не mininet ни k8s-netsim не позволят эмулировать действительные проблемы, их достаточно лишь для изучения каких-то минимальных начальных основ. Например, основные беды openFlow случаются в тот момент, когда сильно кастомный доработанный openVswitch, dpdk и свой контроллер - и ну никак ты их не разместишь на одном хосте, даже если вычислительных ресурсов хоста хватает. Или те же "сетевые топологии в k8s" - это не сеть про сеть, а про упоротый фланнель или сервис-меш )
божечки... вы б лучше рассказали как подружить инфраструктуру и затертый богами agile
у наших решений есть две проблемы - 1) отсутствие стандартизации вместо с велосипедостроением - в итоге cisco с juniper прекрасно строят ipsec, а вот S-Terra с VipNet - нет, хотя ГОСТ, который впрочем описывает только алгоритм... 2) все наши решения - это linux на x86, ну или в последнее время на arm. Ну то есть шифрование на процессоре общего назначения, который при этом еще и роутит и линукс на себе запущает... никаких гарантий времени шифрования/дешифрования, чтоб можно было выстроить простую и логичную обработку трафика
зачем это на хабре?
вы вообще понятия не имеете как работает tcp или веб-сервера. tcp именно дожидается того, что все нужные пакеты придут и более того, если пришли 1 и 3, а 2 не пришел еще и попросит отправить 2 еще раз. Есть такой механизм - selective acknowledgements.
Веб сервер не замрет от этого, потому что существуют неблокирующие операции чтения из сокетов и многопоточность.
Далее про кафку: продюсер устанавливает с брокером две tcp сессии - одну для метаданных, одну для сообщений. И если продюсер не будет принудительно у себя в недрах закрывать объект кафки (KafkaProducer.Close в python, например) после каждой отправки сообщения, то все сообщения будут ходить в рамках одной tcp-сессии и как бы там пакеты по сети не ходили петлями, если таки tcp-достижимость сохраняется (tcp-сессия не разорвалась) - то с одного продюсера сообщения попадут в топик именно в том порядке, в каком их отправлял продюсер.
стек tcp/ip гарантирует, что к ПРИЛОЖЕНИЮ-получателю данные придут в том же порядке, что и отправило ПРИЛОЖЕНИЕ-отправитель. пакеты-то по сети придут как им вздумается, но вот на уровне драйвера tcp они отлежатся, пока не соберутся как надо и уже на уровень приложения попадут как надо.
так себе... так, почему же фабрика все таки IP? В тексте нет ответа на этот вопрос.
Второе интересное место - отдельная сторейдж сеть - мотивация к ней тоже странная - "Это сделано для предотвращения пересечений клиентского трафика, чтобы виртуальные серверы не работали с дисками через интернет, а общались в изолированной сетевой плоскости SAN" - зачем? Изоляция ради изоляции может быть решена в рамках одного порта без лишнего дорогого оборудования. Нет ни слова про qos, loseless ethernet и чуствительность трафика систем хранения к потерям.
кластер - это несколько узлов выполняющих одну задачу. бывают кластеры для повышения производительности общей системы (hadoop), кластер для повышения емкости (кластер гипервизоров), так и кластеры для повышения отказоустойчивости (failover cluster, например у Cisco ASA или MS Failover Cluster).
по поводу балансеров: балансер служит для двух целей - обеспечение бесперебойной работы того что он там балансирует и соответственно сам не должен становиться точкой отказа; распределение нагрузки. Ни nginx, ни haproxy не умеют ничего самостоятельно про второй пункт. А еще ngnix про себя сам думать ничего не может, потому что он F5 ;)
ах, да - кто это сказал, что они best-in-class? хоть кто-то из софтовых решений умеет в аппаратное ускорение шифрования, например?
ну то есть вы предлагаете вместо того чтоб взять просто squid засесть за пересборку или вообще за программирование? ну так в принципе и хлеб напильником можно резать, да )
ядро это умеет без лишних софтов.
1) gre-туннель или l2tpv3-туннель можно забриджевать с eth и l2-трафик из eth будет улетать в туннель.
2) vxlan
nginx и haproxy - НЕ балансировщики ) это reverse proxy. например, из важных функций балансировщика у nginx и haproxy нет возможности кластеризации, т.е. обеспечения отказоустойчивости - надо городить что-то с помщью другого софта типа keepalived, pacemaker и т.п.
F5 LTM, Citrix NetScaler, Kemp - это балансировщики.
что-то, мне кажется, вы сильно не понимаете, что такое прокси.
есть forward proxy: это софтина перенаправляет запросы от пользователей к серверам в интернет. То есть, в браузере у пользователя вы явно настраиваете адрес прокси (ни или curl -x) и браузер идет к проксе и говорит "дай мне страничку", а прокси устанавливает новое соединения, возможно с другого интерфейса, получает страничку и перекладывает ее в пользовательское соединение. Это - 3proxy, squid, tinyproxy, etc...
есть reverse proxy который ставится в обратную сторону. Это по сути обычный веб-сервер принимающий запросы от пользователей из интернета и перенапавляющий их другим веб-серверам. Это - nginx, haproxy, traefik, apache, etc.
вы в своей задаче в посте описываете обычный каскадированный forward proxy и продукт берете соответствующий. А в комментах вам советуют reverse proxy и вы пишите - пробую, интересно, но ничего не выходит. И не выйдет: ngnix и haproxy - это reverse proxy, они для другого. У forward proxy и reverse proxy (web server, по-факту) даже формат get запроса разный:
https://www.oreilly.com/library/view/http-the-definitive/1565925092/ch06s05.html
а с каких пор частоту стали называть герцовкой? с тех самых как до написания статей добралась школота не окончившая и 7 классов?
так в современной ИБ внутренний нарушитель считается более опасным чем внешний.