Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Первый выпуск свободной PaaS-платформы Cozystack на базе Kubernetes"	+/–
Сообщение от opennews (??), 21-Фев-24, 13:19
Опубликован первый выпуск свободной PaaS-платформы Cozystack на базе Kubernetes. Проект позиционирует себя как готовую платформу для хостинг провайдеров и фреймворк для построения частных и публичных облаков. Платформа устанавливается напрямую на сервера и охватывает все аспекты подготовки инфраструктуры для предоставления управляемых сервисов.  Cozystack позволяет запускать и предоставлять по требованию Kubernetes-кластера, базы данных и виртуальные машины. Код платформы доступен на GitHub и распространяется под лицензией Apache-2.0... Подробнее: https://www.opennet.me/opennews/art.shtml?num=60637
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от Аноним (2), 21-Фев-24, 13:21	+1 +/–
больше абстракций богу абстракций!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18, #98

3. Сообщение от xxx000111 (?), 21-Фев-24, 14:04	+1 +/–
Flant?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #11, #22

4. Сообщение от Аноним (4), 21-Фев-24, 14:13	+1 +/–
У фланта подобная штука называется deckhouse.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

9. Сообщение от 12yoexpert (ok), 21-Фев-24, 15:07	+7 +/–
когда уже закончится эта истерия с "облаками"...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12

11. Сообщение от Quad Romb (ok), 21-Фев-24, 15:36	+/–
У фланта свой форк кубвирта в энтерпрайз версии декхауза. С их слов, они умаялись патчи в кубвирт проталкивать. Да и компетенции у них - будьте любезны. Но эта штука тоже выглядит интересно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #23

12. Сообщение от Quad Romb (ok), 21-Фев-24, 15:40	–4 +/–
Нет уже никакой истерии. Люди пользуются и втягиваются. Не каждый может под свои задачи выстроить инфраструктуру - выгодней её арендовать с командой поддержки всего этого хозяйства. Так что всё давно закончилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #19, #27

14. Сообщение от Аноним (14), 21-Фев-24, 15:44	+3 +/–
^^^ Может ещё этой команде "поддержки" и все свои коммерческие данные отдашь чтобы они вдоволь на них анализе заработали оптимизируя качество опусташения твоего кошелька?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #16

15. Сообщение от Quad Romb (ok), 21-Фев-24, 15:48	–2 +/–
Колхоз - дело добровольное. Можно просто придти к тому кто держит деньги и просто сказать ему, что хочешь построить свою инфраструктуру. И людей под неё нанять. Всё будет дома, но стоить будет дороже, а будет ли доступность обеспечена по нужному классу - так то никому неведомо. Ясен пень, что тот, кто держит деньги - будет такому сказочному предложению крайне рад.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

16. Сообщение от kvaps (ok), 21-Фев-24, 16:00	+/–
Зачем, если можно взять коробку и не допускать вендора к своей инфраструктуре и своим данным?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #17, #25

17. Сообщение от Quad Romb (ok), 21-Фев-24, 16:07	+/–
Не всегда можно. Хочется чтобы не падало, выдерживало попадание метеорита и был кто-то кто всё быстро починит по свистку. Это реально недешёво. В любом случае, чувствительные данные можно на своей стороне разместить, а всё остальное в облаке. Провайдеры сами такой сценарий предлагают для опасливых граждан.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #31

18. Сообщение от Всем Анонимам Аноним (?), 21-Фев-24, 16:10	+3 +/–
Не так чтобы много абстракций. В Openstack там вообще ужас. А kubernetes API можно использовать для чего угодно и очень удобная концепция, если разобраться. На небольших масштабах работает очень хорошо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #93, #100, #114

19. Сообщение от Всем Анонимам Аноним (?), 21-Фев-24, 16:15	+2 +/–
Я видел как минимум 2 проекта при мне, которые провалились в том, чтобы с облаками конкурировать. Учитывая сколько возможностей добавляется, это практически невозможно. Самая большая проблема обычно - надежное хранение. Люди думают, что поставят ceph и все, дело сделано. А потом оказывается, что кто-то полез туда что-то чинить и все накрылось. Или автоматизацию сделали вместе всего и эта автоматизация накрыла ceph за пару минут. Распределенные системы, они такие...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #20, #36, #37, #115

20. Сообщение от Quad Romb (ok), 21-Фев-24, 16:18	+1 +/–
Во-во. Ну, вот после таких историй народ в облака и переезжает. Нет, всё можно и у себя развернуть, никто не спорит. Но нужны деньги и толковые люди. Причём толковых людей достать даже посложнее чем деньги. И окупит ли себя такой подход - очень большой вопрос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

22. Сообщение от Аноним (22), 21-Фев-24, 16:44	+2 +/–
От бывшего сотрудника фланта
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

23. Сообщение от qqq (??), 21-Фев-24, 17:25	+1 +/–
в CE версии Deckhouse
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #24

24. Сообщение от Quad Romb (ok), 21-Фев-24, 17:33	+/–
> в CE версии Deckhouse Разве? Когда смотрел, вроде в EE была. Спасибо, посмотрю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

25. Сообщение от Аноним (58), 21-Фев-24, 19:10	–2 +/–
> можно взять коробку и не допускать А к коробке нужно взять вторую, двух админов, а потом ещё две коробки в другом датацентре и ещё одного админа, а потом… А потом окажется, что дешевле и лучше для бизнеса выбросить все коробки к чертям, уволить двух лоботрясов из троих, переместить всё в публичный клауд и по необходимости нанимать контрактников (меня, например) на конкретные проекты, которые потом один админ может админить мержами апдейтов версий софта по необходимости. Или за малый подписочный прайс я сам и смержу, и протестирую, и окно согласую, и выкачу. Я считаю, что это лучшее, что произошло в индустрии за последние 20 лет. Шутка ли, 20-30 часов в неделю в среднем за год приносят ×1,5…×2 денег в сравнении с зарплатным рабством и несравнимо лучшее отношение на личном уровне, что тоже приятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #33

26. Сообщение от Sw00p aka Jerom (?), 21-Фев-24, 19:14	+/–
>DRBD для репликации. это работает?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #34

27. Сообщение от penetrator (?), 21-Фев-24, 19:48	+1 +/–
не дешевле, basecamp сэкономили 7 лямов грина уйдя из облаков и всяких говнокластеров хердокеров абсолютно правильное решение
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #30, #58

28. Сообщение от Легивон (?), 21-Фев-24, 19:51	–2 +/–
Похоже на еще один ненужный проект: кубирнетис для домохозяйки. Неужели есть те кому сложно 1 раз сделать тераформ шаблон своей инфраструктуры для кубера, а затем множить его сколько угодно и поверх катать kubespray + все необходимые сервисы в том же плейбуке? Всего 2 бинарника надо запускать. Сложна, сложна, "ничего" непонятно! Хочу возюкать мышкой в перерывах когда варю борщ или вяжу носки и получать кубирнетис. Слышал о авторе по его докладам в области хранения в кубере. Полагаю lvm csi поверх shared lun сдулся после его ухода их фланта. Это печально. Были большие надежды на эту технологию.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #104

29. Сообщение от Quad Romb (ok), 21-Фев-24, 20:11	+1 +/–
Ну, "нужно-ненужно" - это даже не детский сад. Время рассудит. А автор - это имеется в виду Андрей Квапил? Я не знал, что он ушёл из Фланта. Нет, человек он исключительно грамотный, но во Фланте тоже есть толковые ребята. Думаю, что уж с надёжным хранением они разобрались/разберутся. Тем более, что, с их слов, у них есть несколько сотен инсталляций, которые они поддерживают и постоянно накапливают практический опыт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

30. Сообщение от Quad Romb (ok), 21-Фев-24, 20:18	+/–
Не-а. Не сэкономили. Надеются сэкономить. "Leaving the cloud will save us $7 million over five years." "Will save us" - это "сэкономит". А вот как оно через пять лет "сэкономит" - ну, вот тогда и посмотрим. В любом случае, Basecamp не мог себе позволить работать без облачной поддержки, а поддержка 1-го класса в амазоне, со слов очевидцев, стоит каких-то очень конских денег.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #71

31. Сообщение от нах. (?), 21-Фев-24, 20:37	+1 +/–
Можно, и получить худшее из двух миров - у тебя все падает, рушится от дернутого уборщицей кабеля, и некому чинить (ведь бездельников-админов поувольняли) - и это те самые твои "чувствительные данные", без которых вообще ничего работать не может. Потому что их мало и разворачивать для них полноценную инфраструктуру неэффективно и некому - последний админ на четверть ставки с трудом умеет в некст-некст-некст, какой еще тебе cross-dc sds и резервирование каналов связи. А потом амазон резко замечает что у тебя паспорт не той страны, и у тебя ложится вообще всьо. Провайдеры - предлагают, да, без лоха и жизнь плоха. Но мне очень сложно представить что это у тебя такое ненужно можно разместить в облаке отдельно от "чувствительных данных" и чтоб к тем не открылся внезапно доступ из облака, читай - всего интернета. И скорее всего эти данные очень быстро окажутся именно в облаке, то есть - вообще ничьи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #35, #42

33. Сообщение от нах. (?), 21-Фев-24, 20:41	+1 +/–
А когда тебя через пол-года и след простыл - починить внезапно-упавшую хрень не может никто. Потому что про нее знают только что "где-то в облааааачкаааах". Что я регулярно наблюдаю со всеми долгоиграющими проектами, стяпляпаными руками таких вот горе-аутсорсеров за хороший прайс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #41

34. Сообщение от нах. (?), 21-Фев-24, 20:50	+/–
а почему не должно? Это всего лишь репликация, а не настоящий распределенный кластер. Простая как палка и баш-портянкой где надо подмотана. Вот как первая долька в этом пироге устроена - я действительно не понимаю. Оно ж должно быть чудовищно тормозно. А, хотя у них кажется поверх еще и LINSTOR присопливен, тогда мимо этой этажерки лучше "проходи не задерживаясь"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #38, #55

35. Сообщение от Quad Romb (ok), 21-Фев-24, 20:56	+/–
> А потом амазон резко замечает что у тебя паспорт не той страны, > и у тебя ложится вообще всьо. Зачем - амазон? В России существуют серьёзные клауд-провайдеры. И их даже не два, и не три. А на некоторые из них часть сервисов с амазона переедут на точно такое же апи. Например стрим-апи у яндекс-клауда заявлено совместимым с амазоновским кинезисом. Это не в порядке рекламы, это просто то, что я знаю сам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #44

36. Сообщение от pelmaniac (?), 21-Фев-24, 20:58	+/–
>надежное хранение хранение чего? зачем вообще FS, коли их нет нормальных в природе? а объектных хранилищ номальных как грязи
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #132

37. Сообщение от нах. (?), 21-Фев-24, 20:59	+1 +/–
Ну как будто в ооооблачке у тебя не тот же самый ceph и обслуживают его боги. Просто писка мышек, погребаемых рухнувшими этажерками, на фоне громадных хренилищ никто не слышит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #136

38. Сообщение от Quad Romb (ok), 21-Фев-24, 21:03	+1 +/–
> а почему не должно? Это всего лишь репликация, а не настоящий распределенный > кластер. Простая как палка и баш-портянкой где надо подмотана. > Вот как первая долька в этом пироге устроена - я действительно не > понимаю. > Оно ж должно быть чудовищно тормозно. > А, хотя у них кажется поверх еще и LINSTOR присопливен, тогда мимо > этой этажерки лучше "проходи не задерживаясь" Андрей Квапил, который вроде как является разработчиком этого Cozystack-а, на этой этажерке одного чешского провайдера уже не один год держит. И что характерно - провайдер хоть и частный, но до сих пор не разорился. Так что, действительно - кто не хочет, тот пусть проходит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #49

39. Сообщение от Аноним (39), 21-Фев-24, 21:27	+1 +/–
еще бы хотелось знать что такое PaaS. что это. мне это нужно? кому нужно. а то непонятно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52

40. Сообщение от Аноним (40), 21-Фев-24, 21:39	+/–
Опенстак можно закапывать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #54

41. Сообщение от Аноним (58), 21-Фев-24, 21:42	+/–
Ага, давай расскажи мне про полгода. Мою-то «хрень» как раз починить сможет любой девопс, который не под камнем жил последние лет пять-семь, так как делаю по бест практисес, с документаций и диаграммами. Да иначе и не получится: без диаграммы с клиентом разговаривать особо не о чем, а без документации я и сам в гробу видал помнить все особенности бизнесов, с которыми приходилось работать. В итоге раз за разом оказывается, что клауд надёжнее и дешевле. Деньги не врут, а свои офигительные истории про то, что ты там где-то наблюдал можешь оставить при себе. Я и сам могу порассказать и про хреново сделаную работу, и про то, как «да мы ща без облаков, на дедике всё развернём» оборачивалось убытками с полной остановкой бизнеса от внезапно глюканувшего рейда. Впрочем, я не сомневаюсь, что ты и с диагарммой и документацией не разберёшься в «облааааачкаааах».
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #47, #51

42. Сообщение от Аноним (58), 21-Фев-24, 21:46	+/–
> у тебя все падает, рушится от дернутого уборщицей кабеля > амазон резко замечает что у тебя паспорт не той страны И другие офигительные истории. То уборщица в ДЦ кабеля рвёт, то Амазон начинает банить. Тут уже ничего не поможет: место проклятое. БЕГN оттуда, если ещё не БЕЗНОГNМ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #43, #143

43. Сообщение от Quad Romb (ok), 21-Фев-24, 21:53	+/–
> И другие офигительные истории. ... С амазоном - это не офигительные истории. Это реальная быль, когда ты просто не можешь оплатить счёт, когда даже готов это сделать. Впрочем, люди не из Штатов и их сателлитов сами себе пациенты, если ещё живут на амазоне. Да и для резидентов Штатов, которые делают серьёзные решения, амазон становится всё дороже и дороже. Дабы избежать ненужных споров - про технический уровень амазона ничего плохого сказать не хочу. Эти ввели несколько стандартов, на которые равняются все остальные - это факт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #45, #62

44. Сообщение от похъ (?), 21-Фев-24, 21:54	+2 +/–
Ну а вот ты три года назад - тоже спросил бы зачем амазон, или первым делом в него бы и побежал? > В России существуют серьёзные клауд-провайдеры. сегодня существуют, завтра повторят полет мастерхвоста. Может лучше уж паспорт харошегорусскага купить пока продают, владельцу яндекса вот - дали. > А на некоторые из них часть сервисов с амазона переедут на точно такое же апи. Да, но не дай Б-г вот так еще разок "переехать". Я вот боюсь яндекса. С другой стороны, конечно - too big to fail, но мэйлрушечка хотя бы под правильными пацанами...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #46

45. Сообщение от похъ (?), 21-Фев-24, 22:02	+/–
>> И другие офигительные истории. ... > С амазоном - это не офигительные истории. > Это реальная быль, когда ты просто не можешь оплатить счёт, когда даже еще письма щастья иногда приходят - "мы обнаружили что один или более ваших проектов (но не скажем конечно, какой именно) имеет контактные данные связанные с плохой страной, стреляем на счет три!" И деньгов твоих в принципе не хочут. Хочут чтоб ты валил на счете два. (не амазон, но тоже неплохо получилось) > Да и для резидентов Штатов, которые делают серьёзные решения, амазон становится всё > дороже и дороже. Ну тут либо дорого и плохо, либо плохо и дорого. А onpremise решения мы ж уже похоронили или сделали неимоверно сложными (что вон ажно целый самодельный paas вам выпустили, бесплатно, но это только вход, выход - стольник) и сами вы их поддерживать не справитесь. (и идите пожалуйста нахрен со своим цефом) Теперь, когда мышка влипла в клейстер всеми четырьмя и хвостом, можно начать поднимать температуру.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #64

46. Сообщение от Quad Romb (ok), 21-Фев-24, 22:07	+/–
> Ну а вот ты три года назад - тоже спросил бы зачем > амазон, или первым делом в него бы и побежал? Клиенты туда бежали. И то - не все. Всё мое было здесь и тогда. Потому что я знал что будет, и сейчас тоже знаю, что будет. Просто не рассказываю, чтобы людей почём зря не беспокоить. >> В России существуют серьёзные клауд-провайдеры. > сегодня существуют, завтра повторят полет мастерхвоста А потому что надо вести себя правильно. И все умные люди это понимают. > Я вот боюсь яндекса. С другой стороны, конечно - too big to > fail, но мэйлрушечка хотя бы под правильными пацанами... Переезд - это всегда непростая история. Но я яндекс-клауд не продаю, и рекламой его не занимаюсь. Просто у них много очень толковых технических решений. Реально, вот только один SDN в их облаке взять - уже за это можно снять шляпу. А чтобы жёстко не быть привязанным к одному провайдеру есть проверенные технические и организационные методы. Такая жизнь, надо всегда соломку подстилать - всегда и везде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

47. Сообщение от нах. (?), 21-Фев-24, 22:12	+1 +/–
> Впрочем, я не сомневаюсь, что ты и с диагарммой и документацией не разберёшься в «облааааачкаааах». так я и не стану - это ж аутсорсеры обслуживают? Нам не передавали? Ой как хорошо, просто замечательно, просто прекрасно (что не у меня!). К тому же с амазоном к нам больше не придут, а разбираться в каждом местном аналогов не имеющем - и у каждого такого самоучки без мотора ведь отдельный любимчик - да ну нафиг. Причем куда они там девают прекрасную документацию с диаграмками - я без понятия, но наблюдать за танцами вокруг такого проекта годика через три - незабываемое зрелище. И практика показала что это не зависит от того насколько вменяемыми эти ребята были три года назад. От тех вменяемых за это время никого не остается, даже если юрлицо прежнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #66

48. Сообщение от Аноним (55), 21-Фев-24, 22:13	+1 +/–
> готовую платформу для хостинг провайдеров Оставьте в покое хостинг провайдеров они используют решения Kubernetes as a Service (k8saas) Давайте вместо влажных мечт, я объясню, почему это не готово к внедрению именно у хостинг-провайдеров. 1) Kubernetes и изоляция ресурсов Вопреки бытующему мнению Kubernetes не может из коробки предложить мультитеннантность с жестким разграничением ресурсов. Для хостинг-провайдера нужно создать объект tennant в который входит: - синхронизация учетных данных пользователей из on-prem инфраструктуры для задач управления. Нужна децентрализированная аутентификация и (желательно) авторизация. Tennant сам должен заводить / синхронизировать пользователей, выдавать себе API-ключи и использовать для этого нужно не только OAuth2, но и SAML2. Причем не только на стороне провайдера / AaaS (Authentication as a Service), но также на стороне tennant-а в гибридном сценарии, когда используется его поставщик утверждений (claims). - Количество процессорных ресурсов, выраженных в ядрах или других единицах для вычисления жёсткого порога утилизации CPU - Количество ресурсов оперативной памяти, выраженной в гигабайтах. - Количество сетевой пропускной способности по направлению север-юг, выраженной в скорости траффика и/или в количестве этого траффика в отчетный период - Перечень жестких квот на хранилище, выраженное в форме таблицы. На каждый тип (tier) нужно выдать число гигабайт. Проблема в том, что Kubernetes-кластер не способен жестко отделить ресурсы одного tennant-а от другого. Особенно критично отделить CPU и RAM, потому что остальное можно сделать в другом месте. 2) Kubernetes и ccNUMA Это на мой взгляд самое удивительное, но почему-то люди не в курсе, что в большинстве своём приложения в пространстве пользователя для POSIX-совместимых ОС не поддерживают NUMA. Вся эта эпическая крутизна вокруг shared memory, fork/clone и прочих CoW на буфер родительского процесса вместо нормальной реализации много поточности так прочно засела в головах, что ни преподы студентам не объясняет, как это всё не работает на современном железе, ни студенты не понимают, потому что задач не видели. Сама идея того, что у вас оверкоммитмент по памяти и есть общие буферы прекрасно работает с многопроцессорными серверами типа SMP, но деградирует на серверах с архитектурой ccNUMA. Бредовые разработчики Linux сопротивлялись реальности, говорили, что NUMA слишком сложна и не взлетит. Сюрприз-сюрприз, в 2024 году вы не купите классический SMP-сервер с северным мостом. Везде NUMA. Причем настолько везде, что у десктопных компьютеров ассиметричные ядра не только по тактовой частоте и электропитанию, но и по скорости доступа к контроллерам DRAM или их полному отсутствию у некоторых ядер. Выходите из анабиоза и погружайтесь в реальность: - хостинг провайдер использует преимущественно двухпроцессорные сервера - хостинг провайдер хочет иметь возможность выдать большую виртуальную машину с несколькими узлами NUMA внутри - хостинг провайдер хочет иметь оверкоммитмент исключительно по CPU, и никак не ниже 6, желательно 10. - хостинг провайдер хочет запретить любую форму оверкоммитмента по RAM. Вы понимаете, что планировщик Kubernetes не поддерживает NUMA scheduling в продакшене?! Это барахло можно ставить либо в виртуальную машину, либо на однопроцессорные матери, иначе оно деградирует по производительности. Ну ладно, вроде Red Hat в свежайших версиях OpenShift вывел NUMA-aware scheduling из вечного экспериментального режима, но Kubernetes != OpenShift. Просто я реально удивляюсь с некоторых админов. Неужели вы не знаете, что PostgreSQL (если считать её за промышленную БД) не поддерживает NUMA. И из-за этого в некоторых конфигурациях она работает быстрее на виртуальной машине, чем на физике. Неверная утилизация NUMA может сократить производительность приложения от 40% - 130% в зависимости от того, что лазит через Interconnect-шину. Если и сеть, и хранилище, то 130%. Не удивительно, что виртуализовав PostgreSQL вы снизите производительность всего на 25%. Или подбирайте однопроцессорное железо, а лучше купить нормальную БД. Опять же себе такое ставить... хостинг провайдер продаст вам виртуализированные PostgreSQL, но контейнеризировать её на Kubernetes - гроб. 3) Kubernetes и сетевой стек Я давно перестал следить за очередными обновлениями сетевого стека Kubernetes, потому что там 8 лет уже почти всё готово. Хостинг провайдеру нужно иметь... - Для себя: SR-IOV, RDMA и QoS всенепременно через DCB - Для клиентов: VXLAN-оверлей с Encapsulated Task Offloading, Large Receive Offload, Large Send Offload, Receive Side Scaling То есть если драйверы NVIDIA (Mellanox) у вас не работают, то хостинг провайдеру не нужен такой сетевой стек. Так как там Linux, где вся логика Network Task Offloading, как, впрочем, и NUMA истерически отрицалась с криками "не нужно нам ваше LRO/LSO/RDMA" нужно использовать не стандартное барахло, которое в ядре по ошибке называют сетевым стеком, а драйверы сетевого адаптера и DPDK. Если Cozystack это не оркеструет, то его опять ставить только в виртуальную машину. Особенно интересен Receive Datapath на LRO и его разгрузка (Offloading) 4) Kubernetes и топология сети Хостинг провайдер имеет несколько PoD-ов в смысле центров обработки данных. Между ними находится зачастую L2VPN, поверх которого должна быть создана транзитная сеть с возможностью растягивать L2-домены. Там либо EVPN-MPLS, либо, что чаще сейчас, EVPN-VXLAN. Учитывая, что у хостинг-провайдера много сервисов никто очередной васянский OVSDB держать не будет. Если мы говорим, что это ставится на физическое оборудование, то хостинг провайдеру нужно: - контролировать сетевую изоляцию tennant-авторизация - иметь возможность растянуть его L2-домены между несколькими дата-центрами одного региона (в смысле страны/государства) - иметь возможность назначить Diffserv QoS на SDN - иметь возможность мигрировать данные между дата-центрами Вообще вопрос "конфедерации" (на языке VMware) или "растянутых кластеров" (на языке Microsoft), теоретически можно решить через массовую оркестрацию этого всего в Hashicorp Consul, но как бы можно просто поставить в виртуалку Kubernetes и дать его клиентам так. И PaaS также делать. 5) Kubernetes и хранилище Это вообще притча во языцех. Про гиперконвергентность давайте сразу забудем, потому что в Linux ей либо не пользуются, либо попробовали и УЖЕ не пользуются. Когда планировщик процессов не способен разделить ресурсы, и работать с NUMA, но зато оверкоммитит память и применятся OOM Killer, то хранилище на тех же узлах кластера держать - это самоубийство. LINSTOR по их медиаресурсам не так плох, но я его не ставил еще пока. В свежих версиях его даже можно использовать совместно с RDMA, и он работает на стороне ядра, а не как Ceph. Классическому Kubernetes хранилище можно иметь внешнее и объектное, но, когда у вас там и виртуалки и недо-БД. А вообще см. п.1. Если оно способно выдать программно-определяемое БЛОЧНОЕ хранилище с разными форматами устройств и разными форматами дисков (mirror/erasure coding), то хорошо. Опять же LINSTOR не имеет никакого отношения к теме новости. Нужно просто понимать, как чинить, когда оно ломается. Как именно оно ломается. Какое можно выдать SLA. Но об этом дальше... 6) Kubernetes, резервное копирование и восстановление после сбоев Финиш. Нет отчуждаемого решения. Расходимся. А если серьёзно, см п.4, где я прошу сделать Fault Domains и конфедерации. Теперь давайте сделаем Disaster Recovery для этого решения с возможностью выхода из строя целой локации и возможностью восстановить работоспособность за вменяемое SLA в другом ДЦ. Просто тут еще большой вопрос в цене решения. KVM бесплатен только если его не бекапить. Если нужно решение для Disaster Recovery для хостинг-провайдера с KVM. Ну есть Commvault и с ними можно разговаривать про такие вещи. И если вы думаете, что хостинг провайдеры - это те, кто пишет себе наколенные DR-продукты вы их путаете с админами локалхостов или публичными облаками, которые могут себе это позволить с финансовой стороны. Кроме того, у хостинг-провайдера обычно не только внутренний baclup, но и BaaS-предложение для клиентов с возможностью интегрироваться с on-prem инфраструктурой клиента ("бекап в облако" и прочая маркетинговая фигня). И если этих решений 2, то по деньгам это проблема. Ну как? Становится душно от реальности хостинг провайдеров? Автор новости, конечно, - фантазёр, предлагать такой PaaS "на железе" хостинг провайдерам. Не работает ваш Kubernetes на современном железе, которое экономически обосновано. А собирать проприетарные блейды специально под тот софт, который там вращается - это надо быть кем-то вроде Google Cloud. Или подождите... неужели вы все настолько наивные и думаете, что Red Hat просто так взял и выбросил на помойку RHEV/oVirt. Там же с KVM такие же трудности у планировщиков и при работе с хранилищем и сетью, я бы даже сказал еще большие... Не так страшен KVM, как его libvirt поганый. Kubernetes-кластер хотя бы решает проблемы virsh с миграциями, изменением профиля конфигурации и много чем еще, но привносит кучу своих проблем (etcd и производительность API-сервера). Вы же, я надеюсь, тут все понимаете, что нельзя создать один большой и толстый Kubernetes-кластер на 3000 серверов с сотней тысяч виртуалок и контейнеров. Нужно создавать маленькие кластеры, формировать из них гиперкластеры даже в рамках одного дата-центра и учитывать все миграции между ними и между ними настраивать конфедерации с учетом сетевой топологии. А это делать чем? Что приводит к вопросу интеграций с решениями по управляшкам для хостинг-провайдеров. Про OpenStack даже не предлагайте, это нужно штат минимум из 35 питон-разрабов нанимать, чтобы постоянно менеджить свой форк кодовой базы (несколько команд, на разные модули). Из коробки оно не работает. Но даже если это у вендора купить, то почему бы тогда просто не Kubernetes в виртуалки? Или может быть вляпаться в CloudStack... ой всё. Почитал их github и сайтик... Это наполовину форк OpenShift, который без платного саппорта Red Hat не работоспособен, такова бизнес-стратегия. Лицензия у Cozystack, Apache 2.0... Ну тогда скоро все эти наработки придут в OpenShift. И это при условии, если он взлетит на этом рынке. Red Hat старается, но понятия не имеет что делать. В общем, несмотря на похороны VMware, теперь "by Broadcom" на Bare-Metal OpenShift переходить попахивает экстремизмом. Не то внедрять subj из новости.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #53, #56, #60, #73, #79

49. Сообщение от похъ (?), 21-Фев-24, 22:22	+1 +/–
> Андрей Квапил, который вроде как является разработчиком этого Cozystack-а, на этой этажерке > одного чешского провайдера уже не один год держит. Ну во-первых неизвестно на этой же точно или с мелкими отличиями, во-вторых твою-то этажерку он ловить в полете не собирался. > Так что, действительно - кто не хочет, тот пусть проходит. Ну, скажем так - я точно не хочу на это посмотреть вживую, но если кто-то вдруг пользовался - с интересом послушаю. Если из схемы выкинуть линстор, конструкция выглядит поустойчивей наколенных развертываний ceph'а, ломаться там особо нечему, других сложных мест там просто нет, но вот скорость работы ЭТОГО выглядит крайне сомнительной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #50

50. Сообщение от Quad Romb (ok), 21-Фев-24, 22:28	+/–
> Ну во-первых неизвестно на этой же точно или с мелкими отличиями Строго говоря - неизвестно. > Ну, скажем так - я точно не хочу на это посмотреть вживую, > но если кто-то вдруг пользовался - с интересом послушаю. Хм. Вы недоверчивы, но готовы послушать... Интересно. С таким подходом Вы же всё равно не поверите, верно? А зачем Вам слушать тогда? > Если из схемы выкинуть линстор, конструкция выглядит поустойчивей наколенных развертываний > ceph'а, ломаться там особо нечему, других сложных мест там просто нет, > но вот скорость работы ЭТОГО выглядит крайне сомнительной. Не готов пока обсуждать предметно. Сам это решение ещё не щупал. Но то, что заявлено, что это решение уже не один год работает в коммерческой организации - подогревает интерес к ознакомлению.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #69

51. Сообщение от Quad Romb (ok), 21-Фев-24, 22:34	+/–
> Ага, давай расскажи мне про полгода. Мою-то «хрень» как раз починить сможет > любой девопс, который не под камнем жил последние лет пять-семь, так > как делаю по бест практисес, с документаций и диаграммами. Не ругайтесь. Вас провоцируют. Но в одном человек сильно прав - даже если у Вас замечательные навыки, но Вы один, то Вам будет непросто. Если Вы будете работать хотя бы с маленькой командой, хотя бы ещё плюс пару человек, то руководители будут гораздо охотней с Вами иметь дело. Поставьте себя на место руководителя - вот упадёт на Вас, тьфу-тьфу, рояль. А у руководителя дело встанет хотя бы на несколько дней. На кого ему тогда идти жаловаться, когда ему будут штырь от неба до земли устанавливать? Только на себя, только на себя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #67

52. Сообщение от Quad Romb (ok), 21-Фев-24, 22:47	+1 +/–
> еще бы хотелось знать что такое PaaS. что это. мне это нужно? > кому нужно. а то непонятно. Засовываешь внутрь деньги, а взамен получаешь платформу без головной боли на поддержку, настройку и обеспечения катастрофоустойчивости. Во-всяком случае, все рекламные тексты заявляют именно это.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #57, #74

53. Сообщение от похъ (?), 21-Фев-24, 22:48	+/–
>> готовую платформу для хостинг провайдеров тут скорее - готовую платформу для продажи ее поштучно самим хостинг провайдером. В целом - почему бы и нет. Мож кто и купит из мелких и глупых сам-все-сам. > PostgreSQL (если считать её за промышленную БД) не поддерживает NUMA. И > из-за этого в некоторых конфигурациях она работает быстрее на виртуальной машине, э... и ты можешь обосновать это решение? Процессор-то у нас ровно тот же самый. Больше ядер на кристалл от виртуализации в нем не станет. И если мы не поместились в один - здравствуй либо vNUMA (от которой постгрезу ни жарко не холодно и бесплатные решения ее не умеют) либо снова неэффективное использование памяти уже всей vm. > железо, а лучше купить нормальную БД. Опять же себе такое ставить... сперва надо купить нормальный паспорт. Товар штучный, не каждому губернатору Севастополя продадут. > Или подождите... неужели вы все настолько наивные и думаете, что Red Hat > просто так взял и выбросил на помойку RHEV/oVirt. Там же с а вот с этого места - поподробнее - он его точно-точно не потому выбросил что хочет такое же но чтоб без этих ваших игорь в шва6одку? И что теперь у нас объявлено новым рулезом ? > Почитал их github и сайтик... Это наполовину форк OpenShift, который без платного > саппорта Red Hat не работоспособен, такова бизнес-стратегия. Лицензия у Cozystack, Apache на минуточку - до третьей включительно версии был вполне себе работоспособен. (ну то есть до покупки и назначения правильного менеджера от IBM), ну в смысле - OKD а не openshift(r)(tm) Пихон-девелоперы были прямщасливы что могут обмазываться свежайшим еще до попадания его в редхатовский релиз. А потом... пришел медвед, сел на теремок сверху... > похороны VMware, теперь "by Broadcom" на Bare-Metal OpenShift переходить попахивает экстремизмом. будут поверх опенстека внедрять. Работ на годы, премии менеджерам хорошие обеспечат... И чо я, дурак, до сих пор винду админить не научился, а?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #65

54. Сообщение от Quad Romb (ok), 21-Фев-24, 22:49	+1 +/–
> Опенстак можно закапывать? Не надо. Он просто ушёл на глубину В части контор опенстэк - это более нижний слой под вот этим вот всем. И это весьма серьёзные конторы и отказываться от этого слоя они не собираются даже в страшном сне.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

55. Сообщение от Аноним (55), 21-Фев-24, 22:54	+/–
> Это всего лишь репликация > Простая как палка и баш-портянкой где надо подмотана Что-то я не понял. Мы точно говорим про DRBD 9? https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/ Если построить на этой штуке что-то сложное и понакупить дисков с volatile-кэшем, всякие консьюмерские SSD то можно и без всякого LINSTOR фигурно потерять данные. > Вот как первая долька в этом пироге устроена - я действительно не понимаю. Там же написано "предлагается использование ZFS в качестве базового слоя для хранилища". Сначала Microsoft украл идеи у Sun и сделал Microsoft Storage Spaces, потому присовокупил к нему SMB и RDMA и получил Storage Spaces Direct, который работает посредством блочной репликации в ядре с разделением на блоков данных на "слабы" и реплицирующий их по-своему. Туда же присовокупили тонну всего вокруг erasure coding и сложного кэширования между разными типами дисков в пуле, которым легко прострелить себе ногу, если ты не понимаешь, как это работает, и у тебя бомж-железо c волатильным кэшем и кривыми прошивками. И вот то, что считается в ZFS пулом кластеризовали в ядре. А потом отдали обычным кластерным службам и положили тома (Volume) CSVFS как кластерные ресурсы, поверх которых ReFS. Теперь это всё возвращают обратно вот таким вот способом. То есть если кластеризовать пул ZFS и тома использовать от нее... В общем, круг замкнулся :) > мимо этой этажерки лучше "проходи не задерживаясь" А ты пробовал её лично? Спрашиваю без иронии. Просто технологии вроде DRBD версии 9 крайне сложны под капотом и требуют правильного железа. Далее можно построить поверх этого кластер с соответствующей кластерной FS, там в ссылках приведены примеры вокруг Veritas, GFS и OCFS2. То есть можно в принципе и ZVOL создать... https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #61, #63

56. Сообщение от Quad Romb (ok), 21-Фев-24, 22:57	+/–
Прямо статью написали. И без обсценной лексики. Замечательно, без шуток. > Вопреки бытующему мнению Kubernetes не может из коробки предложить мультитеннантность > с жестким разграничением ресурсов. Нет такой штуки как "Kubernetes из коробки". Вы же это знаете. > - синхронизация учетных данных пользователей из on-prem инфраструктуры для задач управления. Ещё раз - ну, нет такой штуки, как "Kubernetes из коробки". На обслуживание аутентификации и авторизации всё равно придётся сажать людей, которые будут пилить какой-нибудь keycloak, permify или что-то ещё в этом духе. > [и того нет, и сего нет, и вообще ничего нет] .... Ну, аргумент Вы уже знаете. Никто не будет бесплатно выкладывать готовую коробку, которая будет делать всё, что Вам хочется. Что не означает, что вот данный проект совсем бесполезен. Он же Вам не мешает? Пусть себе растёт - авось и вырастет что-нибудь. Или не вырастет. В любом случае, этот каприз не на Ваши деньги произрастает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

57. Сообщение от похъ (?), 21-Фев-24, 22:59	+1 +/–
> Во-всяком случае, все рекламные тексты заявляют именно это. как будто чо неправильное заявляют. Отрезанная голова уж точно не болит. (да и была ли голова у любителя PaaS когда он его внедрять полез?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #59, #110, #144

58. Сообщение от Аноним (58), 21-Фев-24, 23:03	+/–
> basecamp сэкономили 7 лямов грина уйдя из облаков Про то как они не сэкономили, а только собираются, и на каком временном горизонте тебе написали уже. А я добавлю, почему это так происходит. Видишь ли, если пользоваться клаудом не как клаудом, а как нескучным колокейшеном с апишечкой и хостить на нём легаси, то действительно может выйти сильно дороже, чем три админских зарплаты и пара стоек в Эквиниксе. А все продукты 37signals — лютейшее легаси, двадцать лет Ruby on Rails в проде не дадут соврать. И похоже, что для Дэвида Хансона это легаси — почти что религия (что тоже вполне понятно, он автор RoR, и своё детище любит). Кроме того, Дэвид на полном серьёзе гордится тем, что их продукты значительно не менялись внутри все двадцать лет. Поэтому переезд на Амазон для Basecamp что мёртвому припарка, а оптимизировать под клауд Дэвид не даст — для этого нужно доработать архитектуру под возможности клауда (устранение недифференцирующих компонентов и работы, эластичность, динамическое потребление ресурсов, даунскейл в ноль, и так далее), но RoR на такое не рассчитан, а выкидывать RoR — оскорблять чувства верующего с партнёрским статусом. Без адаптации под платформу переезд в Амазон действительно был дорогостоящей ошибкой, даже странно, что никто в 37signals этого не заметил заранее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #94

59. Сообщение от Quad Romb (ok), 21-Фев-24, 23:06	+/–
>> Во-всяком случае, все рекламные тексты заявляют именно это. > как будто чо неправильное заявляют. Отрезанная голова уж точно не болит. > (да и была ли голова у любителя PaaS когда он его внедрять > полез?) Дорога ложку к обеду, а PaaS к проблеме, которую он может решить. Не бывает совсем универсальных решений, никто не спорит. А про рекламные тексты я упомянул, чтобы ко мне претензий не предъявляли. Ведь не я же их составлял - чего же мне за них отвечать, верно? Хотя чем дальше, тем больше эти тексты практически не врут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

60. Сообщение от kvaps (ok), 21-Фев-24, 23:20	+2 +/–
Спасибо за вброс, всё чётко и по делу) > Вопреки бытующему мнению Kubernetes не может из коробки предложить мультитеннантность с жестким разграничением ресурсов Всё так, я всегда говорю что Kubernetes не мультитенантная система. Именно с учётом этого и разрабатывался Cozystack. Касательно тенантов, то конечные пользователи никогда не имеют доступа к management-кластеру. То есть Cozystack выступает в роли бэкенда для сервисов и благодаря декларативному Kubernetes API умеет легко интегрироваться в любую систему. Пользователь может получить в свой tenant Kubernetes-кластер, в отличие от management-кластера tenant-кластера запускаются в виртуальных машинах, которые уже можно жёстко лимитировать. > Kubernetes и ccNUMA На данный момент и Kubernetes и KubeVirt умеет учитывать топологию NUMA. Хотя scheduler на данный момент действительно не умеет, но подвижки в эту сторону есть. В конце-концов, Kubernetes - это свободный проект, если будет спрос, не вижу проблем сформирвать SIG, подготовить пропозал и заимплементить, тем более что опыт и понимание в этом есть. По факту мы только начали, есть много чего дорабатывать, начнём с малого и постепенно будем дорабатывать проект под нужды клиентов. В конце концов тот же OpenShift очень приветсвует когда их решения дорабатывают и адаптируют под ванилу сторонние контрибьютеры. > Kubernetes и сетевой стек > Kubernetes и топология сети SR-IOV в KubeVirt работает из коробки. Мы затащили Kube-OVN, в отличие от других CNI он как раз позволяет делать жесткую изоляцию между тенантами, даже в пределах одного кластера. Можно создавать виртуальные сети и навешивать их на неймспейсы, очень удобно. QoS можно настраивать как на уровне подов, так и на уровне ВМ. Есть поддержка DPDK + можно оффлоадить OVS с разными карточками. Возможность мульти-кластера у OVN тоже есть, но пока что не тестировалась ввиду отсутствия пока такой необходимости. > Kubernetes и хранилище Да, как показывает практика LINSTOR в гиперконвергентной среде работает весьма неплохо. Проблемы начинаются на медленной сети и при геораспределённой репликации. На данный момент мы стараемся не использовать репликацию DRBD, где это возможно и использовать нативные способы репликации для баз данных и стейтфул сервисов. > Kubernetes, резервное копирование и восстановление после сбоев Velero - это стандартное решение для бэкапов в Kubernetes. Но вы правы, для каждого сервиса обычно есть отдельный набор ресурсов который нужно как-то унифицировать. На данный момент есть понимание как это можно улучшить, есть руки, но по прежнему нужны спонсоры :) > Вы же, я надеюсь, тут все понимаете, что нельзя создать один большой и толстый Kubernetes-кластер на 3000 серверов с сотней тысяч виртуалок и контейнеров. Нужно создавать маленькие кластеры, формировать из них гиперкластеры даже в рамках одного дата-центра и учитывать все миграции между ними и между ними настраивать конфедерации с учетом сетевой топологии. А это делать чем? Что приводит к вопросу интеграций с решениями по управляшкам для хостинг-провайдеров. Всё так, у нас есть понимание как делать федерацию. Благо Kubernetes со своей stateless-природой позволяет это сделать достаточно легко. Таким образом каждый кластер становится отдельной зоной, поверх этого напиливается система которая всем этим управляет, умеет умно шедулить сервисы между кластерами. > Это наполовину форк OpenShift, который без платного саппорта Red Hat не работоспособен От OpenShift'а у нас почти ничего нет, мы базируемся на ваниле, все компоненты платформы максимально отчуждаемые и заменяемые. Мы стараемся использовать наиболее стандартный и успешный в индустрии стек технологий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #78, #103

61. Сообщение от похъ (?), 21-Фев-24, 23:23	+/–
> Если построить на этой штуке что-то сложное и понакупить дисков с volatile-кэшем, > всякие консьюмерские SSD то можно и без всякого LINSTOR фигурно потерять > данные. Эта штука вроде как раз исключает возможность построить что-то действительно сложное - данные либо среплицировались, либо запись не подтверждена, либо они нам и на...й были не нужны данные ети. Остальное - как раз проблема нижнего слоя в пироге. А там, опачки, zfs. С ее очень нехорошими свойствами при активной записи и неумением в layered storage. Это далеко не первый случай ее использования в таком виде, но я каждый раз себя спрашиваю - а чо, так вообще-то можно было? > Теперь это всё возвращают обратно вот таким вот способом. То есть если > кластеризовать пул ZFS и тома использовать от нее... отдельно интересно - а там тома-ли? Для drbd логичней иметь дело с файликами. Виртуалке все равно. > А ты пробовал её лично? Спрашиваю без иронии. Просто технологии вроде DRBD всерьез нет, потому что мне пока нигде не было нужно надолго подвальное решение на два тазика и между ними drbd (оно-то будет работать, и да, проверял) а для чего посложнее - все упрется в фс этажом ниже. И вот там блин ТОЧНО не должно быть zfs. С ее lack of resources на исправление уже найденой и локализованной ошибки (кстати, в zvol) > ссылках приведены примеры вокруг Veritas, GFS и OCFS2. То есть можно а вот с этим кто-то другой пусть пердолится. (и вот там можно с drbd вырыть себе отличную глубокую ямку, с хорошими кольями на дне, поведшись на dual-primary - отличная вещь, что может пойти не так-то)   > https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/ тут в принципе можно уже ничего не создавать - потому что вот смотришь на это и думаешь - ну а когда оно заглючит - чинить-то это мы как вообще собираемся, reset-reinstall всему цоду разом? Копаться в этом монстре совершенно бессмысленно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

62. Сообщение от Аноним (58), 21-Фев-24, 23:30	–1 +/–
> Да и для резидентов Штатов, которые делают серьёзные решения, амазон становится всё дороже и дороже. Становится, но не дороже, а дешевле, и не только для резидентов. Я уже больше года сотрудничаю с SAP-интегратором, который специализируется на миграции с on-prem в клауд. Поимённо компании называть не буду, мне ещё с ними долго и продотворно работать, перечислю только бизнес-домены самых крупных клиентов с оборотом от $10bn/год: еда ($165bn один и ~$15bn другой); дистрибуция медоборудования и препаратов (~$277bn); индустриальное оборудование и компоненты (~$13bn); элеваторы, эскалаторы, лифты и обслуживание всего этого ($14bn); телекоммуникационное оборудование и сопутствующие услуги (~$26bn). Как видишь совсем небедные компании, точно сведущие в бизнесе, каждая с большим IT-штатом, от админов до программистов. Без нескольких ERP-систем с доступностью 24×7 такие компании просто неспособны существовать, при этом могут себе позволить любые датацентры под свои нужды. Но всё равно бегут с on-prem в клауд, кто в Амазон, кто в Гугл, кто в Майкрософт. И никакая уборщица им не страшна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #70

63. Сообщение от Sw00p aka Jerom (?), 21-Фев-24, 23:33	+/–
> А ты пробовал её лично? как по мне как была она +-15 лет назад не юзабельной, так и осталась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

64. Сообщение от Аноним (58), 21-Фев-24, 23:35	–3 +/–
> И деньгов твоих в принципе не хочут. Хочут чтоб ты валил на счете два. Так а плохо-то что? Тебе вон все условия создали чтобы быть незаменимым человеком! Свил сетевой кабель из лозы, и лобзиком из берёзоньки процессор выпилил, и никакие облака не нать, диды на счётах считали и мы посчитаем. И нам так спокойнее, глядишь ещё пара лет и не надо будет больше банить адресное пространство AS12389, сами себя забанят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

65. Сообщение от Аноним (55), 21-Фев-24, 23:38	+2 +/–
> э... и ты можешь обосновать это решение? Это пример экстремального случая. Например, если мы возьмем PostgreSQL и поставим его на многопроцессорный сервер, который собрали как бык поSSaл, то есть есть один печальный сетевой адаптер Intel на первом сокете и HBA, которая торчит на другом сокете, то мы получим то самое чудовищное снижение производительности в десятки процентов по сравнению с односокетником, когда растёт нагрузка. Вся идея использовать shared memory, fork-join и прочий OpenMP-образный код в том, что память общая. А она больше не общая. На Intel Xeon Scalable и AMD Epyc у тебя якобы физическое ядро может быть, а доступа к DRAM-контроллеру с него нет. То есть у тебя даже на односокетнике безудержное веселье. Как выходят из положения постгресы и прочие nginx? А вы пойдите в UEFI вашей матери и всё NUMA API отключите. Пусть ОС думает, что у нее все ядра имеют одну и ту же дистанцию. И это вполне официальное решение от автором этого ПО. Иначе гадкая ОС не даёт божественному софту утилизировать эти ядра ввиду нежелания рвать процессы по NUMA. Вот только производительность этого решения (выполнения конкретного запроса) становится лотереей. Ну ок, утилизировали, криво косо работает. Да? Нифига. Если у тебя ни ОС ни постгрес не понимают, что сеть и сторадж на разных узлах NUMA, то у тебя весь сторадж и сетевой трафик польётся через интерконнект-шину. А при этом требования к когерентности кэшей никто не отменял. И что у тебя будет с L3-кэшем при этом. Он будет загажен постоянной передачей данных от HBA и сетевки. Теперь возьмем эту же базу и поместим её на виртуалку к хостинг-провайдеру, который сервер умеет собирать. Чудо-чудное диво-дивное. И потом ты услышишь "Наша база в облаке работает быстрее" и другие офигительные истории от штатных разработчиков предприятия. При этом в базах типа MSSQL и Oracle ты должен: - включить суб-кластеризацию NUMA, то есть сделать так, чтобы каждый процессор в твоем сервере разделился на 2 или 4 узла NUMA, чтобы явно дать привязку DRAM-контроллера к нужной группе ядер - Выключить своё SMT/Hyper Threading и прочий булщит для десктопов - Отключить Hardware Prefetcher и Adjacent Cache, потому что SQL-сервера будут только давать cache miss, они не работают с данными они работают со ссылками на данные, которые потом вновь приходят и обрабатываются в следующем цикле. - симметрично расположить плашки памяти с соблюдением ранговости, чтобы все ядра получили свою память - вырубить фиктивные ядра, если процессор позволяет. У Intel есть серия с "Y" на конце, которая и нужна для SQL. И вот вполне нормально при этом иметь 4-8 независимых узлов NUMA и несмотря на то что у тебя оно никогда не симметрично, всё работает шикарно. Ведь нормальный SQL-сервер: - имеет свой собственный страничный кэш - имеет встроенный сетевой полинг и оптимизатор запросов - сам напрямую производит элевацию мимо стандартных драйверов или имеет единственно верную ФС - имеет кластерную ФС, которая оптимизирована для этой работы, если за ней SAN Обрати внимание, что вся оптимизация делается наоборот. В PostgreSQL ты должен максимально эмулировать поведение сервера 2007-года выпуска. > он его точно-точно не потому выбросил что хочет такое же но чтоб без этих ваших игорь в шва6одку Он его выкинул потому что тащить саппорт: RHEV, OpenStack и OpenShift слишком потно. Особенно потно в случае с OpenStack. Они сели переводить провайдеров на OpenShift, сам по себе RHEV не даёт тебе ничего особенного, а пилить его надо в том же направлении, что и OpenShift вот они и сократили расходы. Они приходили к нам несколько лет назад с туманным предложением "покупайте наших слонов" причем слоны дешевые, дешевле Windows даже. На резонный вопрос "а зачем", ответили что у нас есть новая CSP-программа, которая не понятно зачем нам нужна и мы ничего там не делаем. Просто продаём наш RHEV и поверх него даём OpenStack и спрашиваем, как вы этим пользуемся. Видимо беклог заполняют, облака-то своего нет, а IBM-облако вообще к ним не имеет никакого отношения. Просто если у тебя есть один и тот же криво интегрированный в юзерспейс KVM, который титанически сложно менеджить в крупном развертывании, то зачем тебе развивать 2 конкурирующих между собой продукта, которые его фигово готовят. OpenStack при этом всегда сверху и он не помогает, а скорее мешает с его требованиями к плейсментам схожих шаблонов/флейворов на отдельных кластерах. Он выгоден от 10000 физических хостов и выше. Опять же Red Hat OpenStack залочен на RHEV, а средних размеров хостинг провайдер всегда хочет иметь хотя бы 2 гипервизора. И он дорогой был. Его будут херить тем же способом, что херят остальные опенстеки. Содержат, пока есть провайдер. Не рекомендуют покупать (нам уже не рекомендовали) и вот потом отменяются мажорные апгрейды внутренних модулей. Оно фиксируется в определенном релизе, пока не подохнет. > на минуточку - до третьей включительно версии был вполне себе работоспособен. Ну OKD и сейчас живо, просто это несколько другой продукт сейчас. 3 и 4 разные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #75

66. Сообщение от Аноним (58), 21-Фев-24, 23:43	+/–
> так я и не стану - это ж аутсорсеры обслуживают? Нам не передавали? Ой как хорошо А вот на этот счёт мы с тобой в полной гармонии. Мне как аутсорсеру тоже меньше всего хочется слушать стенания очередного «ветерана» «системного» «администрировая» о том, что без мейкфайла, скрипта на csh и чекаута из RCS^WCVS он даже десятифутовой палкой трогать не будет. Я-то конечно инвойс за часы пришлю, но душа к такому не лежит, и сердце от жалости к старикам стонет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

67. Сообщение от Аноним (58), 22-Фев-24, 00:04	+/–
> Не ругайтесь. И в мыслях не было. Я поха и все его реинкарнации искренне люблю. То, что мы расходимся во взглядах на жизнь делает общение только интереснее. А то, что порой хамит — ну невоспитан, бывает. Я так-то тоже не мать Тереза. > Если Вы будете работать хотя бы с маленькой командой, хотя бы ещё плюс пару человек, то руководители будут гораздо охотней с Вами иметь дело. Работал. Очень сложно контролировать качество, хороших исполнителей крайне тяжело найти с моими весьма скромными скромными оборотами. Но нет худа без добра, пока искал фронтэндщика научился сам интерфейсы делать, теперь он и не нужен особо. > Поставьте себя на место руководителя - вот упадёт на Вас, тьфу-тьфу, рояль. > На кого ему тогда идти жаловаться Не надо ни на кого жаловаться, бизнес-страховка покрывает любой ущерб до пяти миллионов долларов. Я не знаю, что мне надо сделать, чтобы на все деньги навредить. Сжечь фабрику?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #68, #83

68. Сообщение от Quad Romb (ok), 22-Фев-24, 00:10	+/–
> Не надо ни на кого жаловаться, Вот трезвый взгляд на предмет > Очень сложно контролировать качество, хороших исполнителей крайне тяжело найти с моими весьма скромными скромными оборотами Есть такое дело. Но, на мой взгляд, есть некоторые организационные меры, которыми это можно подтянуть. Они не слишком затратны по деньгам, но, безусловно, затратны по усилиям. > бизнес-страховка покрывает любой ущерб до пяти миллионов долларов Хм. Ну, какой бы не была любая страховка - в моих краях она не покрывает ущерб репутации. А эта штука, бывает, стоит подороже любых денег. Лучше, всё-таки, таких ситуаций избегать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

69. Сообщение от похъ (?), 22-Фев-24, 00:21	+/–
>> но если кто-то вдруг пользовался - с интересом послушаю. > Хм. Вы недоверчивы, но готовы послушать... > Интересно. С таким подходом Вы же всё равно не поверите, верно? Ну смотря чему. Сведениям о невиданных узбеках - скорее не поверю, хотя если будут выглядеть убедительно - поставлю галочку что у кого-то вроде бывало. Информацию что воон там и вон там мы нашли отличные новые грабли, приму к сведению, потому что никогда не знаешь на какое поле грабель забредешь завтра. > Не готов пока обсуждать предметно. Сам это решение ещё не щупал. > Но то, что заявлено, что это решение уже не один год работает может им просто быстро и не надо? Контейнер один раз прочитали, и вся нагрузка на сторадж, а пишут они куда-нибудь совсем не туда и там не линстор. Вон там уже автор решения проговорился что "а мы drbd репликацию-то толком и не используем". Опа... а зачем же тогда вообще drbd?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #72

70. Сообщение от Quad Romb (ok), 22-Фев-24, 00:21	+/–
> Становится, но не дороже, а дешевле, и не только для резидентов. Я > уже больше года сотрудничаю с SAP-интегратором, который специализируется на миграции с > on-prem в клауд. Тут, на мой взгляд наличествуют три момента: 0) Не названы порядки сумм затрат до переезда и после. Только обороты. 1) SAP-интеграторы, как правило, интегрируют крайне небедных ребят. И в этих небедных ребятах уже выстроена такая иерархия, что проще потратить лишние деньги компании, чем получить по шапке за то, что что-то упало. В грамотной средней и маленькой конторе траты сверх ожидаемых придётся обосновывать тщательней, чем в большой. 2) Любое облако будет радо принять стабильного и большого платёжеспособного клиента. Ради этого оно будет готово пойти на какие-то индивидуальные договорённости по стоимости. Но только за счёт таких очень больших клиентов смогут выжить не все облака. > всё равно бегут с on-prem в клауд, кто в Амазон, кто > в Гугл, кто в Майкрософт. И никакая уборщица им не страшна. Да, значительная часть маленьких и средних, и даже каких-то больших уйдут в облака. Уже сейчас тенденция видна - тут нет вопросов. Но вопросы вызывают расценки Амазона на премиальную поддержку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #86

71. Сообщение от penetrator (?), 22-Фев-24, 00:37	+/–
там все стоит конских денег, исходящих трафик в сети партнеров 2 цента за гигабайт, 5 центов в сети без пиринга ну что будем считать сколько можно содрать с владельца сайта у которого хотя бы гигабитный аплинк? если качать на всю катушку, то это 10 терабайт в сутки или 20-50 евро в зависимости от тарификации сраный полунано поработает месяц на полную и ты уже должен до 1500 евро )) и это только за трафик инстанса, а еще есть время его работы, CDN и прочая шелуха, у тебя конечно первых 100 ГБ бесплатно, вот так помогли )))) главное на иглу подсадить тех кто нано себе купили за три бакса в месяц с 1 недоядром )))) было 3 бакса, подсели на инфраструктуру - опа 600, заготили поглубже - 6000, сидите плотно - 60000... а Безос себе новую яхту купит > Не сэкономили. Надеются сэкономить. это означает что их издержки сократились на эту саму в пересчете на 5 лет, что я и имел ввиду, ты конечно можешь им не верить, но что-то мне подсказывает что это не звиздеж ))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #76

72. Сообщение от Quad Romb (ok), 22-Фев-24, 00:42	+1 +/–
> может им просто быстро и не надо? > Вон там уже автор решения проговорился что "а мы drbd репликацию-то толком > и не используем". Опа... а зачем же тогда вообще drbd? Думаю, что стоит задать вопрос автору. По-моему он достаточно открыт, чтобы что-то рассказать о своих решениях. Но, вообще-то у него есть насыщенный доклад на DevOpsConf 2022 с подробной презентацией о 450-и картинках. Признаться, я уже немножечко подзабыл подробности, так что пойду ознакомлюсь с ним ещё раз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #111

73. Сообщение от Аноним (58), 22-Фев-24, 00:46	+/–
> Kubernetes не может из коробки предложить мультитеннантность Да и зачем ему это, если проще каждому тенанту дать свой кластер или даже пятьдесят? Что так, что эдак, тенанта будут в итоге биллить за ресурсы, и если кластер не декоративный, то расходы на control plane просто не будут видны. Как решение для провайдеров — кластер с красивым UI — сабж вполне подходит. GKE/EKS/AKS по сути то же самое (если прищуриться как следует). Паковать тенантов в один кластер по неймспейсам не пробовал, наверное, только ленивый, но результат тот же самый, что когда-то с шаредными хостингами: проще каждому дать VPS и хоть убейся там, чем перманентно разруливать пожар в дурдоме. Гордые наследники юниксов в итоге оказались однопользовательскими системами, и эти уши торчат изо всех мест. > Kubernetes и ccNUMA Боль, страдания, ноды на Windows, снова боль и страдания, но уже другие. К счастью нужно не везде и не всегда, а иным микросервисам и вовсе без разницы — всё в один поток и пусть у HPA голова болит. > Kubernetes и сетевой стек Тоже нужно не везде и не всегда, но DPDK решает проблему. Ребята из China Telecom экспериментальную 5G сеть на к8с с DPDK ещё в 2019 показывали. Работало на удивление хорошо, но там к8с чисто декоративный, для запуска подов с hostNetwork. > Kubernetes и хранилище Ох, не начинай. Уж лучше NFS provisioner и пусть у админа СХД голова болит. Для остального есть объектные хранилища. > Kubernetes, резервное копирование и восстановление после сбоев Кластеры одноразовые, быстрее новый сделать, чем поломанный чинить. Как по мне это фича. Ну или сменить etcd  на PostgreSQL и пусть у DBA голова болит ;) >  Вы же, я надеюсь, тут все понимаете, что нельзя создать один большой и толстый Kubernetes-кластер на 3000 серверов с сотней тысяч виртуалок и контейнеров. Как нельзя? Мне айбиэмовцы рассказывали, что kube-proxy до первых ~10к сервисов под нагрузкой норм, но если больше, то начинает заметно тормозить из-за тупенького iptables. Они это правда всё на своём big iron запускали. А так, официальные ограничения 5к нод и что-то там типа 150к подов и 300к контейнеров или около того (точно не помню, давно сертификат получал) и по словам тех же айбиэмовцем «about right».
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

74. Сообщение от penetrator (?), 22-Фев-24, 00:46	+/–
да и рекалама никогда не наепывала нас ))) точно также будешь настраивать и поддерживать, даже девопсов придумали, чтобы всю эту халеру тащить, а когда надоело тыкать мышкой появился Infrastructure as code )) Все тоже самое только за дорого...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #77

75. Сообщение от Oracle (??), 22-Фев-24, 00:49	+/–
> При этом в базах типа MSSQL и Oracle ты должен: > - включить суб-кластеризацию NUMA, то есть сделать так, чтобы каждый процессор в твоем сервере разделился на 2 или 4 узла NUMA, чтобы явно дать привязку DRAM-контроллера к нужной группе ядер А давно Oracle DB научился в NUMA? Потому что для 11 и 12 при установке бареметал прямо в официальной документации было написано обязательно выключить NUMA в биосе сервера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #106

76. Сообщение от Quad Romb (ok), 22-Фев-24, 00:56	+/–
> там все стоит конских денег, исходящих трафик в сети партнеров 2 цента > за гигабайт, 5 центов в сети без пиринга Амазон стал дороже, факт. Но амазон - это ведь не все облака, верно? > это означает что их издержки сократились на эту саму в пересчете на > 5 лет, что я и имел ввиду, ты конечно можешь им > не верить, но что-то мне подсказывает что это не звиздеж )) У меня вообще с верой как-то дела не очень, честно. Я имею дело только с текстом самого Basecamp, где они пишут, что в 2022 году они потратили на облако 3,2 млн., а полные общие затраты на своё собственное железо и место обходятся им в 840 тысяч в год. Выглядит, действительно, как солидная экономия. И тут есть два момента 1) Как тут уже человек написал - их приложение не заточено под cloud-native. Каковы были бы их затраты в облаке при эволюции в этот самый cloud-native, мы уже не узнаем. Basecamp просто не желают этим заниматься. Их законное право, что хотят - то и делают. 2) Что будет с отказоустойчивостью этой штуки за 5 лет работы на собственных мощностях? Это же средство для ведения проектов, которым, как я понимаю, многие пользуются. Если оно ляжет хотя бы на полдня-день за эти пять лет - клиенты могут и подрассосаться. Я не желаю им ничего плохого, и не говорю, что они лукавят. Если они так решили и у них всё получится - ну, пусть они будут здоровы, кто против?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #81

77. Сообщение от Quad Romb (ok), 22-Фев-24, 00:59	+/–
> точно также будешь настраивать и поддерживать, даже девопсов придумали, чтобы всю эту > халеру тащить, а когда надоело тыкать мышкой появился Infrastructure as code > )) Все тоже самое только за дорого... Если нужны девопсы со своей стороны, это означает, что приобретён IaaS, а не PaaS. То есть куплено не то, за что заплачено.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #82

78. Сообщение от Sw00p aka Jerom (?), 22-Фев-24, 01:03	+/–
> Да, как показывает практика LINSTOR в гиперконвергентной среде работает весьма неплохо. гипердебилизм работает всегда > Проблемы начинаются на медленной сети и при геораспределённой репликации. у вас медленная сеть, матерь божья, что делать? Сторейдж траффик надо выделить на отдельные сетевые, где там завалялись дак кабеля, лиф свичи. Гео-распределение? протянули кабеля до дц в соседнем квартале? Серьезно? пс: на один только nutanix посмотрите сколько он стоит, гамно и палки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

79. Сообщение от penetrator (?), 22-Фев-24, 01:07	+/–
скажи мне вот только одно, а накой этот геморой если за 30-40 евро я могу купить дешевый дедик, который доступен через 10 минут после заказа, и который будет работать лучше любого контейнера и виртуалки? с рейдом 0 с nvme дисками на 500 гигов или терабайт могу заказать таких хоть хульярд и построить кластер, failoverIP/floatingIP, GeoDNS, все доступно и это мы про дешевые сервера, но можно ведь и самолет арендовать, и мне не нужно для этого становится AS и поддерживать все свою сеть, любой DC предоставит тебе физическое оборудование и техническую поддержку, и все это будет стоит сильно дешевле, чем городить огород из облаков, которые еще и оверхед имеют неслабый вот зачем оно в теории как клиенту с такими то ценами на дедикейтед?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #84, #108

80. Сообщение от OpenEcho (?), 22-Фев-24, 01:26	+1 +/–
Click->Next->Next->Next->Production Чудеса да и только...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #99

81. Сообщение от penetrator (?), 22-Фев-24, 02:19	+/–
> Амазон стал дороже, факт. > Но амазон - это ведь не все облака, верно? Всегда были конскими и Амазон и Эйже. Я помню еще со времен когда мы их базу юзали. Залез на Vultr ради прикола - цены такие же плюс минус как Амазон. > 1) Как тут уже человек написал - их приложение не заточено под cloud-native. нет такого понятия, это полная херн в уши писать, особенно с точки зрения экономии средств > 2) Что будет с отказоустойчивостью этой штуки за 5 лет работы на собственных мощностях? то же самое, что из облаками, за 840 тыс я уверен они построили добротное решение и дело не в том что они лукавят, а в том что это реальность, которую я могу на своих собственных проектах подтрогать куда меньших масштабов и сравнить эффорт на других аналогичных проектах, которые в облаках крутятся и где они обсираются с кластерами и сидиэн чтобы вывезти т.е. у меня помимо них и свой опыт имеется и статистика, и измерения времени загрузки по географическим регионам
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #89

82. Сообщение от penetrator (?), 22-Фев-24, 02:20	+/–
иди зайди на линкед и посмотри сколько девопсов под облака торчит вакансий
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #85

83. Сообщение от Аноним (83), 22-Фев-24, 02:21	+/–
> бизнес-страховка покрывает любой ущерб Так говорят продавцы бизнес-страховок. Но вот после трахвверха баран-успешный-бизнесмен начинает понимать, что он баран.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #88

84. Сообщение от Quad Romb (ok), 22-Фев-24, 02:27	+1 +/–
Это что-то типа вопроса автомеханика - "А зачем мне отгонять машину в сервис, если я и сам могу её починить?". Ну, может ему и не надо в сервис. Сам справится. Или не справится - что бывает чаще, чем хотелось бы. В любом случае, в такое могут не только лишь все. Ведь не все - автомеханики. И не все - универсальные специалисты по построению отказоустойчивых облаков с заданным уровнем доступности на пачке дедиков по 30 евро за штуку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #102, #117

85. Сообщение от Quad Romb (ok), 22-Фев-24, 02:30	+/–
> иди зайди на линкед и посмотри сколько девопсов под облака торчит вакансий Много. Но это пока. Пока рынок не насыщен, и люди не слишком хорошо понимают, что именно приобретают в этих самых облаках. Стабилизируется рынок приложений под эти самые облака, и ситуация будет меняться. Это же не технический вопрос, на самом деле.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #92

86. Сообщение от Аноним (58), 22-Фев-24, 02:30	+/–
> 0) Не названы порядки сумм затрат до переезда и после. Только обороты. А вот за такое я могу оказаться в суде. По прейскуранту CPU-час на AWS дороже, чем on-prem, это, думаю, не секрет. Как и то, что по прейскуранту платят только залётные или тем, кому на минуточку, только спросить. Например, то легаси которое я для клиентов держу — исключительно на RI крутится и это дешевле аналогичного дедика в любом ДЦ здесь, но за «запустить очередной curl | bash и посмотреть что сломается» я плачу уже по прейскуранту и редко когда больше 50 центов. А крупные компании так и вовсе по прямым соглашениям работают и мы с тобой наверное никогда не узнаем, сколько точно тот же SalesForce платит Амазону за CPU-час (одно точно — сильно меньше, чем ты или я, даже со всеми оптимизациями). К тому же, в контексте SAP, стоимость CPU-часа не является драйвером. > 1) SAP-интеграторы, как правило, интегрируют крайне небедных ребят. Это сильное преувеличение. К тому времени, когда компании нужен SAP, у неё обычно есть деньги и на лицензии, и на интеграцию, и понимание как именно это вписывается в бизнес-процесс. Интеграторы так и вовсе на любой кошелёк найдутся, вплоть до фрилансеров на локальных рынках труда. Считай, как 1С, только в кожаных шортах и поёт йодлем. > 2) Любое облако будет радо принять стабильного и большого платёжеспособного клиента. Ради этого оно будет готово пойти на какие-то индивидуальные договорённости по стоимости. Но только за счёт таких очень больших клиентов смогут выжить не все облака. Более того, все основные провайдеры сами предлагают и персональную цену, и помощь в оптимизации расходов начиная с какого-то уровня. В фантазиях опеннета Безос лично только и ждёт, чтобы раздеть догола незадачливых кастомеров. В реальности же саппорт AWS сам предлагает помощь, иногда даже бесплатно. У меня в позапрошлом году был клиент, у которого слили через троян админский аккаунт и на все деньги там накуролесили. Пообщался с саппортом, пообщался с аккаунт-менеджером и билл как по волшебству на 80% сдулся. Такой вот оголтелый капитализм, при котором лояльность клиента важнее, чем стоимость подержаного седана премиум-класса. > Но вопросы вызывают расценки Амазона на премиальную поддержку. А какие вопросы вызывает-то? Базовые вопросы решаются бесплатно, а для бизнеса «$100 или 10%…3% от билла в зависимости от размера билла» не траты. Ну если совсем плохо, можно рядом с домом фрилансера найти. Или меня нанять, я мелких клиентов обслуживаю «по подписке» ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #87

87. Сообщение от Quad Romb (ok), 22-Фев-24, 02:49	+/–
> А вот за такое я могу оказаться в суде Я не выведываю здесь тайн публично и зла добросовестным внедренцам не желаю. Пусть тайное останется тайным, и так тому и быть. Я просто к тому, что - ну, раз нет цифр, то что я могу об этом рассуждать, верно? > По прейскуранту CPU-час > на AWS дороже, чем on-prem, это, думаю, не секрет Такой себе секрет, естественно. >> 1) SAP-интеграторы, как правило, интегрируют крайне небедных ребят. > Это сильное преувеличение. > Считай, как 1С, только в кожаных шортах и поёт йодлем. Ну, хорошо, возможно я сгустил краски. Но, как говорится, тенденция прослеживается. Кстати, 1С теперь тоже шьют на любой размер. >> Но вопросы вызывают расценки Амазона на премиальную поддержку. > А какие вопросы вызывает-то? Базовые вопросы решаются бесплатно, а для бизнеса «$100 > или 10%…3% от билла в зависимости от размера билла» не траты. Я описываю то, что слышал сам. На полноту охвата не претендую, всё может быть. У людей от стоимости этой поддержки оставались негативные впечатления. > Или меня нанять, я мелких клиентов обслуживаю «по подписке» ;) Спасибо, без шуток - никогда не зарекаюсь о таких вещах не говорить. Но амазон я уже не рассматриваю в силу причин, в том числе, и внетехнического характера. Я просто подводил к двум выводам, суть которых в том, что: а) переезд в облака - это реальная неумолимая тенденция хоть и для многих, но не для всех. б) сейчас у облаков начнёт все больше обозначаться разбиение по классам заказчиков. Причём не на два класса - "мелкие и большие", а с гораздо более мелкой дискретизацией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #90

88. Сообщение от Аноним (58), 22-Фев-24, 03:01	+/–
Спок, всё свачего. Продавцу бизнес-страховок национальная торговая палата прямым текстом запрещает лгать под страхом отзыва лицензии и принуждению к исполнению обязательств. У нас страхование само себя урегулировало до абсурда — на любой вид деятельности (считай, под каждый industrial code) есть «стандартная» страховка, две трети предложений различаются тольк логотипами. Сам полис около 20 страниц и там ничего сложного не написано: национальная торговая палата предписывает писать понятным обывателю языком. Человек, неспособный понять 20 страниц простого текста не сможет зарегистрировать бизнес — не осилит заполнить форму.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

89. Сообщение от Quad Romb (ok), 22-Фев-24, 03:09	+/–
>> 1) Как тут уже человек написал - их приложение не заточено под cloud-native. > нет такого понятия, это полная херн в уши писать, особенно с точки > зрения экономии средств Есть такое понятие. Это не совсем рекламная штука. Хотя без рекламы не обошлось, естественно. Кстати, вот хорошо было бы запилить какой-нибудь игрушечный проект в двух параллельных вариантах, чтобы людям можно было на пальцах это показывать. Возможно такое даже уже где-то есть, не знаю, не смотрел. >> 2) Что будет с отказоустойчивостью этой штуки за 5 лет работы на собственных мощностях? > то же самое, что из облаками, за 840 тыс я уверен они построили добротное решение Никогда ни в чём я не уверен, в чём я досконально не разобрался. И другим не рекомендовал бы под такой уверенностью подписываться. Отказоустойчивость на три геораспределённых реплики они сделали? Не знаем. Вот то-то и оно. > т.е. у меня помимо них и свой опыт имеется и статистика, и > измерения времени загрузки по географическим регионам Слушайте, ну если у Вас всё нормально работает на Ваших решениях - значит всё Вы под свои задачи хорошо сделали. Если хорошо работает - пусть так и дальше работает. Тут только нюанс есть - это сделали Вы и под свои собственные текущие задачи. Но нельзя же продавать всем костюмы одного универсального размера, верно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #91

90. Сообщение от Аноним (58), 22-Фев-24, 03:31	+1 +/–
> Я просто подводил к двум выводам, суть которых в том, что: > а) переезд в облака - это реальная неумолимая тенденция хоть и для многих, но не для всех. Как минимум, останутся маргиналы-селфхостеры. Я все эти облачные технологии очень люблю, но при этом в гараже-то локалхост пыхтит — полезная в хозяйстве вещь, да хоть тот же сервер майнкрафта детям запустить. > б) сейчас у облаков начнёт все больше обозначаться разбиение по классам заказчиков. Причём не на два класса - "мелкие и большие", а с гораздо более мелкой дискретизацией. Каждому клиенту персональное предложение. С нарастающим уровнем автоматизации это стоит всё меньше и меньше, и стремится в какой-то гротескный вычислительный коммунизм — каждому по потребностям, от каждого по карману. Но всё равно все недовольны. Парадокс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

91. Сообщение от penetrator (?), 22-Фев-24, 04:38	+/–
> Кстати, вот хорошо было бы запилить какой-нибудь игрушечный проект в двух параллельных вариантах, чтобы людям можно было на пальцах это показывать. Возможно такое даже уже где-то есть, не знаю, не смотрел. давай для начала расскажешь за архитектуру в двух словах? уверен на сотку, что шляпу загонишь > Отказоустойчивость на три геораспределённых реплики они сделали? а что там делать, все на линухе поднимается, опен-сорс решения, ну мозги нужны, а это не такая уж большая проблема, ну переберут сотню кандидатов и найдут я перефразирую оригинальное сообщение, я конечно свечку не держал, но уверен что за 840 тыс нашли они тех средства и людской ресурс > Тут только нюанс есть - это сделали Вы и под свои собственные текущие задачи. почему универсального размера? я продаю подход, и открыто говорю, что есть неприемлимо для какого-то другого проекта я сделаю другое решение, но принцип и метрики будут те же и облака в принципе не вписываются, они изначально ущербные для прода, ничего кроме сомнительного удобства они не несут это не значит что я отказыаюсь от провайдеров услуг, ну того же DNS, конечно можно свой BIND поднять, MaxMind купить, но нужно считать, что выгоднее, как и колокейшен, можно арендовать, можно купить нужно считать, но история с говноконтейнерами, оркестраторами, виртуализацией и прочей шляпой от гиперскейлеров за очень дорого сюда не входит, это история про бабки... бабки Безоса
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #95, #105

92. Сообщение от penetrator (?), 22-Фев-24, 04:40	+/–
уже лет 5-6 пожалуй все стабилизируется но никак не стабилизируется настройку баре-метала меняешь на оркестрацию облаков, так еще и за оверпрайс, найс )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #101, #107

93. Сообщение от Аноним (93), 22-Фев-24, 04:59	+/–
А чем Kubernates API лучше или хуже VirtualBox API?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #137

94. Сообщение от _ (??), 22-Фев-24, 05:10    Скрыто ботом-модератором	+/–
Трепло :) Эти ребята (37signals) были в клаудах (оне в AWS и GCP) дольше чем ты в школу ходишь... И до них таки дошло (С) Правда для окончательного диагноза нужно знать чего они in-prem намутили. vmWare к примеру - всио, значит - что? OpenShift? А сторидж - что? А сеть? И тд и тп. Хотя это всё паравоз не остановит :( К примеру железо тоже всё г0внистeе и дороже становится ... Совпадение??? ;-) Вот так вас нежно в клауд и загонят. Не всех, но большинство.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

95. Сообщение от _ (??), 22-Фев-24, 05:14	+/–
>за 840 тыс нашли они тех средства и людской ресурс Маловато вообщето! Это зарплата на всего то 7 инженеров в год. Которые должны свой-не-клауд-но-как-клауд держать 24/7/365 ... Звиздят они где то!(С)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #118

96. Сообщение от Олег (??), 22-Фев-24, 05:28    Скрыто ботом-модератором	+1 +/–
Linstor в связке с zfs.... Дальше можно не читать, это невероятное поделие, под капотом которого вы проведёте не одну неделю.... Это мрак....
Ответить | Правка | Наверх | Cообщить модератору

98. Сообщение от Аноним (98), 22-Фев-24, 08:22	+/–
Вот они гумна и палок намешали. Развалится вся эта куча ведь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

99. Сообщение от Sw00p aka Jerom (?), 22-Фев-24, 08:47	+1 +/–
> Click->Next->Next->Next-> шо за не ГОСТ-овая терминалогия, там же написано иначе: х*як, х*як и в продакшен :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

100. Сообщение от Аноним (100), 22-Фев-24, 09:41	+/–
Опенстак это питоновские обертки над квм и уже с ним. Какой ужас то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #138

101. Сообщение от похъ (?), 22-Фев-24, 09:51	+/–
> так еще и за оверпрайс, найс > ))) поди чо плохое? "нам этих денег все равно не заплатят!" Ну и вот тебе ж в клювике решение принесли, когда можно ничего даже не настраивать, кроме pxe загрузчика - все остальное интуитивно-приятные скрипты сделают за тебя и ты снова можешь вернуться к дерганию на игогошечке нескучных рест-апи. Ну да, ну да - сэкономили на эффективности, переплатили еще и за железо. Зато девляпс, инфраструктурка-ass-in-cocococode, и можно ничего не чинить. Так победим! Рыночек хавает и добавки просит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

102. Сообщение от похъ (?), 22-Фев-24, 10:06	+/–
> Это что-то типа вопроса автомеханика - "А зачем мне отгонять машину в > сервис, если я и сам могу её починить?". тут скорее - зачем покупать в салоне если сосед подешево (вообще-то нет) продает перевертыша битого в зад и в морду, а я со свалки могу понабрать запчастей хоть десять таких восстановить. (при этом личные успехи заканчиваются единственным экземпляром да и тот на даче в огороде стоит и не ездит) Пойдешь работать в таксопарк где у руля такой механик? Вот и я думаю что если только сторожем, тырить там точно нечего. > И не все - универсальные специалисты по построению отказоустойчивых облаков с заданным > уровнем доступности на пачке дедиков по 30 евро за штуку. точнее, их таких вообще нет. Есть у них только пачка дедиков (причем по 130 с налогами скорее) - и на них вротпресс без обновлений. Нет, это тоже рыночек и тоже продаетца до сих пор, но по сути этот механик у нас в колхозе без конца чинит ржавые жигули соседям. А у кого-то уже пара своих таксопарков за это же время и при тех же или меньших трудозатратах образовалась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #109

103. Сообщение от Аноним (106), 22-Фев-24, 10:44	+1 +/–
Специально полез посмотреть, Red Hat вывел из экспериментального статуса планировщик с поддержкой NUMA https://docs.okd.io/4.14/scalability_and_performance/cnf-num... Причем сравнительно недавно... > tenant-кластера запускаются в виртуальных машинах, которые уже можно жёстко лимитировать. Ну то есть это и есть k8saas, потому что теннанты виртуализированы. Тогда всё понятно, тогда это нормально. Просто я подумал, что это очередное решение сделать железный кубик для хостинг провайдеров без изоляции. К нам такие приходили с предложениями "купите нас". Не скажу кто, потому что есть надежда, что исправятся. Если клиентские Kubernetes виртуализованы, OVS можно оффлоадить в Cozystack и SR-IOV работает, значит у проекта есть будущее. Просто с учетом той нагрузки, которую порождает репликация хранилища в Ethernet сетях и скорости адаптеров у хостинг провайдеров сложилось предпочтение в выборе вендора... В общем сетевая карточка может быть любой если это Mellanox. Начиная с ConnectX-5 можно тестировать функционал offloading для Cozystack. > Проблемы начинаются на медленной сети и при геораспределённой репликации. LINSTOR, как я посмотрю начал бесплатно выкладывать DRBD-транспорт для RDMA. Причем когда я говорю RDMA я имею в виду RoCEv2. iWarp ввиду тотальной деградации OEM-вендоров последних шести лет, фактически не существует в готовых решениях. Помер вместе с вендорами сетевок, которые его поставляли. Сейчас нужно отдельно Chelsio покупать, если он реально нужен. Всё настолько плохо с ним, что вся Azure перелезла на Mellanox и RoCEv2, который проектировался при участии MS. Внедрение сети готовой к RoCEv2 - это как раз решение по вопросу репликации гиперконевергентных хранилищ. Логика простая: В рамках PoD-а датацентра (в смысле комнаты) должна быть честная выделенная Spine-Leaf фабрика. В каждой стойке поднимается DCB с PFC и ETS (стандартное резервирование иерархического QoS для RDMA-приоритета на 50% большинство задач покроет) и обязательно ECN. Каждая стойка имеет L2 и держит гейтвеи на ToR, а наверх пойдёт L3 с роутингом по BGP. Трафик сети хранения при этом должен перекраситься из 802.1p в DSCP, где его вновь встречает PFC, ETS и ECN. При переходе в любую собственную транзитную фабрику вы снимаете PFC и оставляете только ETS+ECN. В этой ситуации DRBD должен правильно заворачиваться в RoCEv2 и не просить кушать. При этом кластер у вас должен стоять в одной стойке (L2), а любое внешнее хранилище идущее по NFSv4 или iSER может находиться в той же комнате в соседних стойках. Если приспичит, что-то мигрировать, из комнаты в комнату, ETS и ECN вас спасут, при условии тюнинга DCQCN-буферов. Далее начинается самое интересное. Если у вас есть требование по репликации данных сквозь Data Center Interconnect между отдалёнными локациями вы должны делать это объектно, а не блочно. В рамках комнаты у вас всё блочно, а если кластер растянут, то - нужны свидетели, которые мониторят кластер в каждой локации в которых он присутствует - свидетели могут не участвовать в кворуме в рамках локации, если там нечетное количество узлов, а могут и голосовать - есть отдельный вами написанный протокол, который мониторит состояния свидетелей отдельно от основных кластерных узлов - трафик свидетелей желательно дублировать дополнительно через OOB мимо BGP-фабрик, потому что сами понимаете почему =) - трафик этой репликации идёт любым подходящим объектно-файловым способом, только не блоки. Эта нагрузка считается трафиком север-юг и подпадает под её квотирование для клиентов и QoS. То есть каждая локация должна дать Fault Domain. В идеале, есть волшебная цифра 4, когда от каждого кластера в каждой стойке есть примерно по 4 сервера и один кластер присутствует не более чем в четырёх стойках. Тогда у вас Fault Domain-ы будут диск-сервер-стойка-локация. Если применяются блейды, то это сложнее, потому что нужно еще учитывать выход из строя шасси. Тут нужно привязываться именно к LINSTOR, что они предлагают. И вот если всё это строить на оборудовании, которое сертифицируется под Azure Stack HCI, то это будет даже надёжно работать. Особенно это касается подбора HBA и дисков. Вопрос только в SDN-контроллере. VXLAN в такой сети используется не только для клиентов, но и для растягивания L2-доменов оверлея этих клиентов. То есть, другие услуги провайдера скорее всего уже используют VXLAN и есть OVS на физических коммутаторах, а на транзитной сети шлются Type 5 маршруты EVPN по которым ходят ДРУГИЕ VXLAN-ы, соединяющие VRF-клиентов, которые, например, арендуют физические сервера. Следующая чисто хостинг-провайдеровская задача притащить этот VRF из одного датацентра в другой и положить на виртуальный коммутатор в Cozystack. Ну то есть интеграция с каким-нибудь Juniper Contrail крайне важна, потому что иначе при внедрении продукта Cozystack окажется в собственном сегменте сети, в изоляции... и дальше по тексту. Что касается БД, то там вообще DRBD не нужен, там же всегда одна и та же формула: - синхронная репликация в локации - асинхронная репликация между локациями - логическая асинхронная мульти-мастер репликация с CRDT между регионами (странами) Хранилища максимально локализированы. Просто зарезервируйте под это 10% на ETS в PoD, большинству хватит. В общем, желаю вам успехов =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #128, #134

104. Сообщение от 2Desmond (ok), 22-Фев-24, 10:46	+2 +/–
Полагаю lvm csi поверх shared lun сдулся после его ухода их фланта Нет, работы продолжаются. В ближайшее время ожидаю релиз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

105. Сообщение от Quad Romb (ok), 22-Фев-24, 10:56	+/–
Не, шляпы я не продаю - я по другой части. На самом деле в основе там всё просто, как эта самая шляпа. Дъявол в деталях, как всегда. Хорошо, пройдём по шагам. Пусть их будет четыре. 1) Что обозначает модное "cloud-native" на практике? Это означает, что все (или большая часть) функций приложения распилена на микросервисы, которые общаются друг с дружкой по заранее оговоренному API. Там ещё много всякого, но это вот основная черта таких приложений. 2) Что это нам даёт? Это нам даёт две вещи: а) головную боль, потому удержать в голове всю лапшу взаимодействий становится сложнее. Это рекламная неправда, что идёт упрощение приложения. Где-то упрощается, а где-то понимать становится сложнее. б) Возможность динамически распределять функции приложения по значительному количеству узлов используя возможности оркестратора 3) На практике это означает важную штуку, что настроив планирование приоритетов и правила масштабирования оркестратора мы будем платить только за те возможности облака, которые реально требуются в данный момент. Ненужные рабочие узлы будут исчезать, а в случае роста нагрузки они будут появляться. 4) Строго говоря, мы можем написать вот это вот самое облачное приложение не для контейнеров, а для виртуалок, и даже просто железных машинок. Если с такими псевдоподами нам позволяет работать оркестратор. Но при этом подходе возникает такая штука, как "крупная гранулярность". В переводе с рекламного на русский это значит, что нарезать нагрузку оркестратор станет гораздо большими кусками, чем в случае с контейнерами. Что влечёт за собой то обстоятельство, что много ресурсов начнёт уходить в обрезки. То есть платить за эти ресурсы придётся - но вот работать они толком не будут. А недоутилизированные оплаченные мощности - это крайне скучная история.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #122

106. Сообщение от Аноним (106), 22-Фев-24, 10:56	+/–
Во-первых, это если у вас Oracle стоит на Linux, а во-вторых они постепенно добавляли поддержку начиная с 10. Сейчас уже 19.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

107. Сообщение от Quad Romb (ok), 22-Фев-24, 10:59	+/–
> уже лет 5-6 пожалуй все стабилизируется но никак не стабилизируется И, значит, не стабилизируется никогда? Лады, в таких дискуссиях нужно откладывать обсуждение на какой-то срок. А то будем бездоказательно перебрасываться вот этим вот "стабилизируется - не стабилизируется".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

108. Сообщение от Аноним (106), 22-Фев-24, 11:05	+2 +/–
> вот зачем оно в теории как клиенту с такими то ценами на дедикейтед? Потому что клиент разный. Это ты себе дедик поставишь и настроишь, а другой клиент хочет именно что вот так вот. Есть клиент, который хочет получить теннант виртуализации внутри которого ТВОИМИ скриптами он поднимет себе кубики, постгресы, редисы и прочее и соединит это себе с домашним через terraform. Потом его девопсы будут бегать к тебе в техподдержку, которую ты им продаёшь за отдельные деньги. Это реальность, нравится тебе это или нет. Мне, например, не нравится. Я тоже дедик бы брал на стороне клиента.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #119

109. Сообщение от Quad Romb (ok), 22-Фев-24, 11:10	+/–
> тут скорее - зачем покупать в салоне если сосед подешево (вообще-то нет) > продает перевертыша битого в зад и в морду, а я со Не, не скорее. Скорее, медленнее. Корректно именно сравнение, когда сапожник спрашивает, зачем ему покупать сапоги. > Нет, это тоже рыночек и тоже продаетца до сих пор, но по сути этот механик у нас в колхозе без конца чинит > ржавые жигули соседям Что-то у Вас пессимизм какой-то сплошной. Не хватает только балалайки, самогона и медведя в лаптях для полной картины. Но на полной картине их, почему-то, нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #113

110. Сообщение от InuYasha (??), 22-Фев-24, 11:28	+3 +/–
так ведь Pain As A Service
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

111. Сообщение от похъ (?), 22-Фев-24, 12:04	+/–
А, и действительно. Не тратьте клик, я все за вас нашел: https://pixeldrain.com/u/RNU2WMXd Дальше листать не стал, поскольку и так все ясно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #112

112. Сообщение от Quad Romb (ok), 22-Фев-24, 12:08	+/–
Хм. Спасибо, конечно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

113. Сообщение от похъ (?), 22-Фев-24, 12:14	+/–
> Корректно именно сравнение, когда сапожник спрашивает, зачем ему покупать сапоги. жене! (соседу и так далее) Потому что сам-то он не сороконожка и ему на локалхосте оно и точно не нать. Зачем тебе дома paas? Жегули в огороде - понятно. А автоматический завод по их производству - нахрен в огороде не вперся. Даже небольшой. А вот если сапоги покупаются (или шьются) на продажу - то тут уже возможны разумные варианты ответа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #116

114. Сообщение от voiceofreason (?), 22-Фев-24, 12:16	+1 +/–
Как раз на больших. На небольших ванильный кубер руками поднимать это оверкилл и извращение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #139

115. Сообщение от voiceofreason (?), 22-Фев-24, 12:19	+/–
Если тебе надо городить аналог ютуба, конечно имеет смысл только подписочная дрянь, на "всё своё" разоришься. А мелочёвку всю локально не поднять это уже профнепригодный админ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #133

116. Сообщение от Quad Romb (ok), 22-Фев-24, 12:21	+/–
> Зачем тебе дома paas? Жегули в огороде - понятно. А автоматический завод > по их производству - нахрен в огороде не вперся. Даже небольшой. По хорошему - незачем. > А вот если сапоги покупаются (или шьются) на продажу - то тут > уже возможны разумные варианты ответа. Но вот человек, с его же слов, не для дома решения тачает. Так что это к нему надо ответы переадресовывать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

117. Сообщение от penetrator (?), 22-Фев-24, 16:13	+/–
очень дебильное сравнение, может быть наоборот? облака - это автосервис у ашота, которые делают все быстро но с пеной и 4 см шпатлевки на кузове? внешне красота а внутри шлак для масмаркета, так еще и развод на деньги --- а всем и не надо на проекте обычно есть архитектор, который знает что делает на очень крупных проектах есть аж целых три разных по должностям архитектора если разработчик пишет систему в которой не разбирается, то и облака ему не помогут
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #120

118. Сообщение от penetrator (?), 22-Фев-24, 16:15	+/–
>>за 840 тыс нашли они тех средства и людской ресурс > Маловато вообщето! > Это зарплата на всего то 7 инженеров в год. Которые должны свой-не-клауд-но-как-клауд > держать 24/7/365 ... Звиздят они где то!(С) нах там 7 инженров? один держит лампочку а четыре крутят стол?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

119. Сообщение от penetrator (?), 22-Фев-24, 16:19	+/–
я же не говорил, что это не реальность, вот только я спросил ЗАЧЕМ или хотя бы ПОЧЕМУ и в твоем сообщении ответа нет, а мне в голову кроме маркетинга не приходит, волна хайпа, модно молодежно доткомы тоже когда-то были популярны с зп рядового джависта в 200К в год, а потом сдулось все
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #121

120. Сообщение от Quad Romb (ok), 22-Фев-24, 16:23	+/–
> очень дебильное сравнение... > может быть наоборот?... > внутри шлак для масмаркета ... > и развод на деньги Очень аргументированно. Вот ей-ей, не найду ничего возразить на такие продуманные доводы. Ну, значит, на сём и порешим. И пойдём заниматься дальше тем, что каждого устраивает > если разработчик пишет систему в которой не разбирается, то и облака ему > не помогут А кто спорит? Архитектор должен знать, что он строит. Но если каждый разработчик будет знать хотя бы общую структуру взаимодействия своего участка с соседними, то  это снимет гораздо большое количество проблем, чем кажется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

121. Сообщение от Quad Romb (ok), 22-Фев-24, 16:32	+/–
> я же не говорил, что это не реальность, вот только я спросил > ЗАЧЕМ или хотя бы ПОЧЕМУ Ответ прост - масштаб и мобильность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #125

122. Сообщение от penetrator (?), 22-Фев-24, 16:45	+1 +/–
1) а если у тебя приложение недостчтоно большое, или не имеет таких контекстов, чтобы его распилить его на микросервисы, то все свое взаимодействие внутри приложения (которое может быть как правильно так и неправильно организовано) перенесешь на уровень инфраструктуры и деплоймента потом где-нибудь на реддите появляются сообщения что из-за сложности взаимодействия микросервисов девелоперы на проде плавающие баги месяцами ищут в том числе у таких монтров типа Amazon короче микросервисы ради микросервисов - НЕ РАБОТАЕТ 2) а) головную боль, потому удержать в голове всю лапшу взаимодействий становится сложнее. Это рекламная неправда, что идёт упрощение приложения. Где-то упрощается, а где-то понимать становится сложнее. так сам же подтверждаешь б) Возможность динамически распределять функции приложения по значительному количеству узлов используя возможности оркестратора ога-ога, только это вертикальное масштабирование, а не горизонтальное, scale up можно и без микросервисов, а если ты хочешь микросервис в горизонтальное масштабирование, то туда можно засунуть и немикросервисное приложение, можно выделить часть (но зачем?) его API и предоставить наружу, через HAProxy, в любом случае это настолько незначительные изменения, что ими нельзя объяснить пятикратной выгоды BaseCamp. т.е. микросервисы в данном случае нужны только, если тебе критически важно масштабировать горизонательно разные части твоего приложения ПО-РАЗНОМУ, например из-за стоимости лицензий, особенностей интеграции, или использования специфического оборудования, ну или по какой-то другой технической причине, 80% проектов если не больше не нуждаются в микросервисах и их по ошибке используют, как средство упрощения процесса разработки, но работает это далеко не всегда, и появляется необходимость в девляпсах, которые это все будут заводить в прод, агрегируя результаты работы подкоманд, как по мне ужасное решение по проектным процессам 3 и 4) ты будешь платить так что тебя оно будет раздевать, потому что оверпрайс там при масштабировании идет на порядок выше и более, т.е. можно с запасом взять второй дедик, чтобы загрузка пиковая была не более половины мощностей и при увелечении докупать аренду еще одного и это все равно ОЧЕНЬ ДЕШЕВЛЕ, чем брать облака в соотвествии в потреблением!!! т.е. другим словами "простой дедика" стоит намного дешевле чем "загрузка облаков" только в случае с дедиком у тебя предсказуемые, условно-фиксированные, и само собой более низкие счета и никак наличие нескольких сервисов с дополнительным сетевым оверхедом не позволит тратить мне меньше на инфраструктуру, не убедил
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #123

123. Сообщение от Quad Romb (ok), 22-Фев-24, 16:57	+/–
> короче микросервисы ради микросервисов - НЕ РАБОТАЕТ Любое "что-то" ради него самого - это не то, чем стоит заниматься. А я разве говорил, что всё надо обязательно микросервизировать? >>..  Где-то упрощается, а где-то понимать становится сложнее. > так сам же подтверждаешь Я показываю сильные и слабые стороны такого подхода. Зачем же мне обманом заниматься? >  scale up можно и без микросервисов, Можно. Я ниже и описал, что это даже на пачке железных машинок можно делать. И недостатки этого тоже описал. > и их по ошибке используют, как средство упрощения процесса разработки Они, действительно, могут упростить какие-то части разработки. Но не всегда и везде. Я, во всяком случае, этого не говорил. > не убедил Ну, убеждать заочно - дело такое себе. Аргументы свои я добросовестно предоставил. Красным подчеркну - как и любой инструмент, облака решают свои задачи. Но абсолютно универсальным средством облако являться не может - чего ж тут стесняться-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #124

124. Сообщение от penetrator (?), 22-Фев-24, 20:07	+/–
> А я разве говорил, что всё надо обязательно микросервизировать? ты говорил, что это способ залезть правильно в облако (и бейзкэмп этого не сделал) а получается, что большинству приложений микросервисы не нужны, то логично, что и облака не нужны ну вот круг и замкнулся, укусил ты себя за хвост ))) а рынок тем не менее продолжает кушать облака, гиперскейлеры богатеть, и дело точно не в техническом обосновании решения и у меня нет другой причины кроме как маркетинг, по-крайней в таких объемах и таких ценах
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #126

125. Сообщение от penetrator (?), 22-Фев-24, 20:11	+/–
>> я же не говорил, что это не реальность, вот только я спросил >> ЗАЧЕМ или хотя бы ПОЧЕМУ > Ответ прост - масштаб и мобильность. ну звиздеж же!!! ну какой масштаб? тебе не хватает количества инстансов у крупных европейских и азиатских ДЦ? или мобильность - это про оплату трафика на переезд в другой ДЦ? или может про проприетарные базы данных типа Dynamo DB? ну я не знаю как так можно сцать в уши дружище )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #127

126. Сообщение от Quad Romb (ok), 22-Фев-24, 21:33	+/–
> ты говорил, что это способ залезть правильно в облако (и бейзкэмп этого > не сделал) Верно. Говорил. > а получается, что большинству приложений микросервисы не нужны, то логично, что и > облака не нужны Хм. А откуда это - "получается"? Вот не вижу я этого большинства (кстати, из кого это оно выделено) которому облака категорически не нужны. > ну вот круг и замкнулся, укусил ты себя за хвост ))) Не-не, круг надо ещё дорисовать, чтобы я на такое членовредительство согласился. > и у меня нет другой причины кроме как маркетинг, по-крайней в таких > объемах и таких ценах Ну, тут частично справедливо именно в части цены. Что там было про круг и про хвост? Вот это оно самое - людям не предлагают чёткий рецепт эволюционировать (или создать) их приложение в облачном стиле. Сами люди в этом не сильно разбираются, и достаточно разумно предпочитают не рисковать. А в стиле необлачном это их приложение может кушать ресурсы на негуманные деньги. Ну, как говорится: "Это же не проблема - это возможность!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

127. Сообщение от Quad Romb (ok), 22-Фев-24, 21:46	+/–
> ну звиздеж же!!! > ну какой масштаб? тебе не хватает количества инстансов у крупных европейских и > азиатских ДЦ? Под масштабом подразумевается возможность управлять ростом обрабатываемой нагрузки с очень маленьким шагом. > или мобильность - это про оплату трафика на переезд в другой ДЦ? Мобильность - это возможность автоматизированно поднять облако у одного провайдера, потушить облако у второго и сделать это так, чтобы живые пользователи в результате пострадали не слишком. > или может про проприетарные базы данных типа Dynamo DB? Не надо закладываться в хранении данных на те сервисы, API и возмножности которых присутствует только у одного провайдера. Вот я бы так не стал делать. Если бы мне вот так уж захотелось использовать Dynamo DB, то я бы провёл серию тестов c ScyllaDB, чтобы убедиться, что в случае переезда у меня не возникнет неразрешимых проблем. Просто у сциллы заявлено наличие совместимого с динамодб апи. Как оно там на самом деле - уж не знаю. > ну я не знаю как так можно сцать в уши дружище ))) Ну-ну, давайте соблюдать коммуникационную гигиену. Хуже нам от этого не будет, это точно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #129

128. Сообщение от Sw00p aka Jerom (?), 23-Фев-24, 00:26	+/–
> В общем, желаю вам успехов =) и сколько это все будет стоить? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

129. Сообщение от penetrator (?), 23-Фев-24, 04:08	+/–
ясно понятно )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

130. Сообщение от Аноним (130), 24-Фев-24, 00:02    Скрыто ботом-модератором	+/–
Какие-то два ноунейма решили запилить свой велосипед из пачки деталей от других велосипедов. Доверия не вызывает.
Ответить | Правка | Наверх | Cообщить модератору

131. Сообщение от Роман (??), 27-Фев-24, 09:13	+/–
На HN полная тишина, не то что на какую-нибудь очередную запускалку NodeJS . @kvaps, просто любопытно, откуда (с ресурсов каких тематик, если можно имена ресурсов) идут переходы и интерес?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #135

132. Сообщение от Роман (??), 27-Фев-24, 09:16	+/–
а время так вообще достать невозможно - очень такой фактор для многих, думаю
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

133. Сообщение от Роман (??), 27-Фев-24, 09:19	+/–
наблюдаю вокруг SMB, с уклоном в малый бизнес, отсутствие понимания что такое вообще "системный администратор", просто как класса нет такой сущности в головах у людей. Глобально это скорее хорошо, конечно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

134. Сообщение от Аноним (134), 27-Фев-24, 17:51	+/–
Простой вопрос. А где ты такие знания получил, что почитать можно по этому поводу?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #142

135. Сообщение от kvaps (ok), 28-Фев-24, 00:15	+/–
Не понял, идут переходы куда? Откуда звёздочки на гитхабе или что? Но вообще мы тут довольно много шумим: и реддит, и хабр, и kubernetes.io :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #145

136. Сообщение от кстати (?), 01-Мрт-24, 13:15    Скрыто ботом-модератором	+/–
простите, вы не брат поха?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

137. Сообщение от Всем Анонимам Аноним (?), 05-Мрт-24, 19:01	+1 +/–
> А чем Kubernates API лучше или хуже VirtualBox API? Там есть такая штука как Custom Resource Definition. Очень удобно использовать как в инфре, так и в приложениях. Сильная вещь. Можно чем угодно управлять в принципе на основе одной системы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

138. Сообщение от Всем Анонимам Аноним (?), 05-Мрт-24, 19:03	+/–
> Опенстак это питоновские обертки над квм и уже с ним. Какой ужас > то? 3 млн строк кода сложно назвать "оберткой". Там много всяких вещей включая установку на железо тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

139. Сообщение от Всем Анонимам Аноним (?), 05-Мрт-24, 19:04	+/–
> Как раз на больших. На небольших ванильный кубер руками поднимать это оверкилл > и извращение. Все зависит от определения "небольших". Соглашусь, что на совсем маленьком масштабе это даже и опасно, там много движущихся частей и если не знать, то можно пострадать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #140

140. Сообщение от voiceofreason (?), 06-Мрт-24, 19:02	+/–
Небольших это где накладные расходы на возню с кубером больше причиняемой им пользы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #141

141. Сообщение от Всем Анонимам Аноним (?), 09-Мрт-24, 17:13	+/–
> Небольших это где накладные расходы на возню с кубером больше причиняемой им > пользы Это из серии, что "все люди в мире кроме меня глупые". Может хотя бы попробовать почитать про kubernetes прежде чем комментировать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

142. Сообщение от Тоже интересно (?), 26-Май-24, 11:05	+/–
А ещё, посоветуйте, пожалуйста, линки на книги и документацию в т.ч. на тему кластерной HA BigData в Кубере. Greenplum, Clickhouse, etc. только без вот этого всего тормозного от Apache. Где удобно публично доступный легко устанавливаемый оператор и чарт к Greenplum? Что-то не видно их на artifacthub.io И неплохо было бы добавить их и в Cozystack, btw. ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

143. Сообщение от Маленький маленький Педро (?), 26-Май-24, 21:03	+/–
> БЕГN оттуда Stop Ganstalking, Stopa!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

144. Сообщение от Маленький маленький Педро (?), 26-Май-24, 21:17	+/–
> (да и была ли голова у любителя PaaS когда он его внедрять полез?)   Позвольте узнать, чем так плох полностью open-source PaaS, например, PostgreSQL со свободными операторами и т.п.? Т.е. то, что при необходимости можно легко поднять самостоятельно в том же Cozystack, например, в своей собственной серверной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

145. Сообщение от Просто интересно (?), 26-Май-24, 21:36	+/–
А ведь у Linbit был даже вариант коммерческого контракта, обеспечивающего SLA? И кто нам тут в уши водичку льёт? Уж не святые ли производители "сверхнадёжных" проприетарных хоронилищ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема