Нельзя кусать руку, которая кормит. Опенсорс - это достояние человечества. Опенсорс - это общественная собственность на средства производства. Тех, кто участвует в ОПП надо носить на руках, а не персты всякие являть их взору.
Проблема как раз в том, что команда небольшая. Пусть команда будет одна(или несколько под одним началом), но большая и подготовленная государством (со школы). Тогда результат станет сопоставим с Debian, возможно даже станет круче, если будет бесплатным в т.ч. для коммерческого пользования. Не будет малый бизнес покупать Linux, как и не покупал Винду. Будут использовать на свой страх и риск бесплатное. И если в один прекрасный день сработают заплатки и бесплатное остановится, то такая ситуация будет проблемой государственного масштаба (так как произойдёт это, скорее всего в рамках государства по географическому признаку).
P.S. Командам инженеров, которые тянут эту лямку - бесконечный респект. Возможно, им нужна помощь в виде квалифицированных кадров, или хотя бы надежды на то, что эти кадры когда-нибудь появятся в промышленных масштабах.
Было бы бесплатным для коммерции - выбрал бы Alt. Хотя Fly на Астре мне тоже оч понравился. За неимением кед, я бы пользовался. Астра запустилась на моём планшето-ноуте lenovo и без плясок работала с сенсорным экраном (почти) а это пока не удавалось ничему, кроме убунты точ. Но убунта это не моё, как и юнити. Гном - тоже не моё.
Увы, мистер Рокфеллер, так тоже не всегда получается. Сейчас именитые производители валят из России и отказывают в поддержке ранее проданных продуктов. То есть вы и цену высокую заплатили и рыбку, так сказать, не съели.
Ну или исходя из такой философии рекомендую купить Rand Rover в повседневное пользование. Дорогой - значит качественный ;)
Да и с тушёнкой такой подход не всегда имеет место быть.
Выбирая из российских дистрибутивов и импортозамещающего софта, приходят те же мысли что и при выборе тушёнки в супермаркете. Каждый раз я трачу кучу времени, читаю что написано на банке, трясу и т.д. и в итоге, как правило, ем не то, что ожидал. Если бы в магазине была бы одна марка тушёнки, но она была бы добротной, то меня бы этот вариант устроил бы больше, чем её ассортимент. На каждой баночке своя наклеечка, у каждого свой директор, некоторые производители даже тратятся на рекламу. То есть деньги тратятся не на качество самого продукта, а на что-то для меня вторичное. Я не за наклейками прихожу в магазин, и не за тем, чтобы трясти банки, а за тушёнкой.
Так же и с дистрибутивами. Чтобы что-то там гарантировать гос. корпорациям, надо осуществлять аудит кода перед компиляцией пакетов. Какая частная лавка потянет такой объём работ на постоянной основе? Где вы возьмёте столько IT-шников (которые будут действительно проверять открытый софт на закладки)? То, что пакеты старые в российских дистрах значит, что конторы их выпускающие не могут позволить себе проверку софта часто. То есть мы будем вынуждены либо пользоваться устаревшими пакетами, либо наращивать штат людей проверяющих код.
Я уверен, что в российских дистрах рекомендуемых в ФСБ, всё-таки проверяют, но получается так, что люди в разных конторах занимаются одним и тем же - проверяют один и тот же открытый софт. В итоге каждый из них изобретает один и тот же велосипед. Если бы они действовали под одним началом, то они могли бы действовать эффективнее.
Это задачи государственного уровня (свой актуальный репозиторий). Пусть дистрибутив будет один, но уделять ему будут бОльшее время. И не надо будет ставить один дистр, щупать, потом другой, щупать, потом возвращаться к первому. Дистрибутив, по сути - набор пакетов. Если изготовитель не может выпускать актуальные пакеты, значит дистрибутив худшего качества, чем западные бесплатные аналоги.
До прочтения этой статьи я планировал попробовать altlinux, а теперь не хочу. Сомнения по поводу переезда на отечественный софт начались после ознакомления с ценами на отечественные продукты. Эта статья подкинула гирьку на весы "остаться на debian". Не будут дискредитировать дебиан для того, чтобы добраться до нас, нищебродов (малый бизнес). Тем, кто вкидывает деньги на заплатки в ОПП, интересна рыбка покрупнее. Гос корпорациям, конечно, надо переходить на своё. А мы, рабы божьи, ставим debian и крестимся двумя руками, уповая на милость заграничных инженеров.
Это я к чему всё это... Чтобы репозиторий был актуальным, надо чаще обновлять пакеты. Чаще обновлять - больше человекочасов, чтобы было откуда взять больше человекочасов, надо больше человек, чтобы было больше человек - их надо больше учить. Учит в промышленных масштабах - только государство. То есть государство должно потратить большее количество денег на обучение, для того, чтобы три (или сколько их там) частных лавочки, получили толковых инженеров и больше стригли денег с пользователей? Государство должно заниматься этим вопросом. Информационная безопасность - стратегическая задача. Бизнес никогда не окупит затрат, которые необходимо потратить на ИБ, достаточную для гос уровня. Спецоперация кончится и по нам будут работать на другом фронте, информационном. Специалисты, которые будут по нам работать - подготовлены вражескими ГОСУДАРСТВАМИ, а не частными конторками. Они пройдут через компетентность специалистов от бизнеса как нож через говно.
Не пробовал. Гугл тоже не в курсе, что за "бинарная репликация postgresql" Может есть какие-то иные названия?
Нашёл. Это физическая. Да, пробовал. Без неё не знаю как ещё делать почасовые копии. Меня весь этот механизм удручает. А именно держать разные базы в разных службах Postgres для того, чтобы вести почасовые копии какой-то одной базы. Либо все базы будут в твоей копии, либо делай логическую. Я для себя пришёл к выводу, что просто надо заводить несколько постгресов под разные базы, и рисовать какую-то управлялку.
Спасибо. А то собирал скриптами инструмент, который позволяет держать почасовые копии постгри почти так же удобно как MSSQL. Правда под винду. Сейчас запланировал переход на постгри на линуксе, а тот в свою очередь находится на zfs (lxc, чтобы избежать лишних слоёв виртуализации). Снапы поудобнее, чем ловить этот WAL. Попробую, в общем.
Я ставил на mdraid сначала. При первом использовании zfs я жидко обосрался, так как при простом зеркале из простых домашних SATA массив просто был никакой. При нагрузке iowait взлетал в небеса и не спускался. Тогда я поставил дебиан на зеркало mdadm стандартным текстовым инсталлером и сверху накатил проксмокс. На mdadm массив заработал, так как и должен был. (система грузилась на обоих дисках по одиночке). С zfs на стенде что я только не делал, разве что в церковь не ходил. Потратил на него где-то месяца два и так не добился приемлемой производительности. Даже с вынесеными zil и кэшем на ssd. Потом ещё через пол года и год были такие же копания гугла и эксперементов по месяцу где то. Узнал много нового, но ключевое так и не познал, видимо.
Результат дала установка SAS контроллера и самых простых SAS (7200 6Tb) дисков с двумя m2 дисками по 128. M2 разбиты на 100 и 28, 28 в зеркале - zil, 100 кэш на чтение в страйпе. Массив потянул примерно 25 терминальных рыл, но вешал работу при отправке почасовых снапов на бэкап сервер, от чего пришлось отказаться (оставил только суточные). Мне, кстати, попадался вот такой параметр, который я не пробовал ещё: zfs_per_txg_dirty_frees_percent = 0
Спустя какое-то время, обнаружил, что утром, люди испытывают дискомфорт. Я опять давай копать везде и накопал zfs_txg_timeout = 15 вместо стандартных 5. В результате утренние просадки ушли. В общем, я посмотрел наверное все маны первых 5-10 страниц по разным запросам, пробовал всё подряд и по отдельности и в комплексе. Пока я не могу похвастаться тем, что я прям уверен, что у меня правильно настроенный массив (скорее всего это далеко не так). Так или иначе такая сборка сейчас почти не порождает io wait в отличие от далее описанного случая. Возможно тут играет роль серверное железо во главе с нормальным SAS контроллером и дисками.
Мне нужен был максимально быстрый массив, но чтобы он был в zfs и зашифрован. Взял два по 128 для системы, два m2(PCI-E4) по 1Tb, два sata SSD по 512. Первая пара под систему, вторая под массив, третья под вспомогательный массив. Ещё так же был сделан одиночный sata hdd в массив под бекапы. Железо домашнее, но бодрое (Ryzen 7 5800X). Ну и в итоге даже при копировании с зеркала 1Tb m2 на 512 SSD 1С-ной базы (где-то 50 гиг), iowait увеличивается до 25 и чувствуются лаги, если копировать базу на одиночный HDD то io подрывает до 85, на часик. Второе происходит в нерабочее время, поэтому вопрос остро не стоит. Понятно, конечно, SATA, домашнее железо. Но вот почему с зеркала SSD на зеркало SSD на такой машине io заметно увеличивается и даёт дискомфорт, а тот же mdadm на старом компе, со старыми дисками в зеркале не даёт такой io wait (пусть даже при меньшей скорости записи, но я дискомфорта не чувствую). Иными словами у меня складывается впечатление, что zfs пытается засунуть в блочное устройство данные, со скоростью с которой устройство не справляется. Я писал об этом на форуме проксмокса, и там мне посоветовали ограничить скорость записи на виртуальное устройство в самом проксмоксе, в свойствах ВМ. Ну так себе совет, в общем. Подскажите, знающие товарищи, какие ещё параметры покрутить (предлагайте всё, кроме ashift) буду проверять опять по порядку всё подряд. Проблему надо решать. Вопрос не в том, конечно, почему у zfs высокий iowait а у mdadm + ext4 низкий, а почему он НАСТОЛЬКО высокий, и как бы его сделать ниже.
Но с zfs я уже не слезу. Я не знаю с помощью чего ещё нативно можно держать географически удалённую холодную, зашифрованную, почасовую копию любого по размеру массива. С btrfs ещё не знаком, если она позволяет тоже самое, что zfs но не подрывает io то хрен с ним пересяду на на неё.
Про mdadm кто-то писал, что не поддерживается. Знаете, когда проксмокс был ещё 5-ым, там в гуях не было и LVM. Это же не значит, что проксмокс его тогда его не поддерживал. Пользуйтесь хоть чем, proxmox в первую очередь debian, а потом уже всё остальное.
Точно, LTSP... Пардон. Я уже давно ковырял тему, только сейчас вспомнил, что меня беспокоило по части клиента. При подключении к виртуалке через spice прокс даёт файл для клиента spice для единоразового доступа (файл после использования трётся). То есть это некий ticket. Я предполагаю, что средствами самого проксмоса и можно насоздавать пользователей, дать права на просмотр своей машины и через api проксмокса получать такие тикеты через какую-нибудь вебку. Вы так и сделали? Может поделитесь основными api запросами? Тема живая и вполне можно её довести до статьи на хабре. Кто-нибудь может новогодние праздники захочет заморочиться.
То есть пользователь с дома зашёл через vpn в офисную сеть(ну или как-то иначе), попал на самодельную вебку (или блин, вообще на сам проксмокс), получил этот файл, запустил его прям из браузера, и вуаля, у пользователя перед носом полноценный рабочий стол со звуком пробросом USB (блэкджеком).
Знающие товарищи, подскажите, можно ли подключиться spice не в виртуальному рабочему столу, а реальному, то есть к тому, который на данный момент выведен на монитор рабочей станции? Можно ли перехватить реальный звук, USB? Если нельзя... То что уж... Есть X2Go, который точно может(транслировать картинку с монитора), или TurboVNC. Не то пальто, конечно, но что делать.
В общем, если заморачиваться с толстыми клиентами (и к толстым клиентам таки можно подключиться через spice), то должно быть промежуточное звено которое будет знать, где толстый а где виртуалка запущены, и которое будет выдавать файлы для доступа через spice или в проксмокс или к толстому клиенту. Ну а если не заморачиваться, то попробовать сделать на базе api проксмокса. Совсем уж скриптить - лень. И я уже устал поддерживать свои старые рукожопые скрипты десятилетней давности. Когда -то давно было интересно скриптить, сегодня хочется, чтобы было как можно меньше модулей, как работают которые знаю только я (В нашей деревне мало админов работающих с linux).
Без толстых клиентов, наверное на данный момент LTSP+SPICE+PX это самая козырная альтернатива RDP. С толстым клиентом - RDP даже курит.
Где-то год назад пришло озарение, что это, наверное единственная годная альтернатива RDP это и есть Proxmox+Spice+LTSP. Времени на попробовать так и не было. Какой вы использовали клиент (я не про стандартный, а например, который можно запихать в PXE + DHCP)?
Вообще, в офисе можно было бы и не запускать LTSP на гипере. Часть сотрудников, работающих в офисе могут работать на толстых клиентах (у кого железо позволяет). Локально те же кеды будут очень бодры, и полоса пропускания такая не понадобится. Но встаёт вопрос о том, как подключиться к такой машине снаружи, чтобы человек мог зайти в свою терминальную сессию с дома, например. (На данный момент двадцатку лидеров по скачке на sourceforge замыкает TurboVNC, если погуглить, то можно наютубить человека, играющего в какую-то последнюю кваку, через это протокол. Сам - не пробовал. Хотя VNC, конечно не прокинет ни смарткарту, ни принтер, но как простое решение вполне сойдет. Ну или подключиться к локально запущенной Xorg или Wayland через spice. Тоже не знаю, можно ли. Если можно, и прокидываются usb и звук то круто - это оно и есть, терминальное решение, даже круче, чем на базе RDP (за счет толстых клиентов).
Если клиент тонкий, и рабочее место крутится на proxmox, тогда проблем нет - всё централизовано, и всегда мы знаем куда подключаться - на центральный VDI. Но в этом случае не используется возможность запуска LTSP в режиме толстого клиента, в котором не гоняется по сети растровая картинка. Не говоря о том, что тонкие клиенты - это нередко просто старые машины, и некоторые из них вполне ничего и вполне потянут KDE Plasma.
Мой парк тонких клиентах крутится на WTware (Windpows server + RDP). Очень удобно, но хочется Linux на клиентах, полностью opensource решение. 95% моего парка тонких клиентов +/- годные компы и рухлядь, способная отражать картинку на мониторе, два RaspBerry Pi3 B+ На момент установки, самый дешёвый вариант тонкой станции - это Raspberry 3, тогда она стоила 5тыр, а сейчас 10. Столько же, сколько и Rasp 4. Получается самый оптимальный тонкий клиент теперь Raspberry 4(? втварь, вроде ничего, кроме малины, не поддерживает). Вроде как пахнет виндой на arm (или я уже отстал?). В общем варианты есть. Если использовать Raspberry 4, то Plasma на ней будут летать, вместе с 1С, офисом и хромом и 4-х Gb памяти для большинства пользователей - достаточно.
В каждой шутке есть доля шутки... (Я знаю, что VDI это не то пальто, просто идея пришла в голову, вдруг выстрелит).
Извините за сумбурность. Просто очень интересна эта тема, и перекапываю гугл примерно раз в пол года по ней. Очень мало информации. Поэтому спасибо, что поделились реальными данными в части количества машин и полосы пропускания.
Времени на скрипты почти нет. Да и поддержка таких нововведений может сорвать другие работы. Поэтому жду решения из коробки и в редкие часы досуга, пробую всякие spice, x2go и т.д. Пока ближе всех конечно же spice. X2Go - это прям разочарование, даже с KDrive - шляпа. Deskpool ещё не смотрел, думаю в НГ каникулы поиграться. Предварительно понял только, что бесплатно там что-то только в отношении RDP, будет ли там хорошо работать удалённая убунта (через RDP?) есть сомнения.
Если с помощью spice можно подключиться не к виртуальной машине, а к реальной, пробросив звук и USB, то можно сказать что это будет самое интересное решение по VDI (смесь толстых и тонких клиентов, с возможностью подключаться к толстым клиентам снаружи). Есть люди у которых есть в офисе рабочая станция, а есть те, которые работают из дома. Первым нужны ресурсы proxmox, а вторым - нет. У нас в организации, например перевод на толстые клиенты почти полностью бы разгрузил терминальную машину, и убрал бы нагрузку на локальную сеть.
Пока, полученное, для меня непонятно. Сначала разберусь с sanoid, потом буду штудировать zfs. Там, похоже надо порядочно ещё почитать. И оборудование как раз подъедет. Вот мой красавчик. Вот ещё неплохой красавчик, если кому надо, но уже он как-то неприлично дорого стоит. (Стоил 1200 где-то)
а может быть вы просто заменили диски 5400rpm на 10000rpm, а разницу приписываете SAS.
и там и там 7200. Контроллер… ну на mdadm тот же контроллер и был. Можете погуглить «zfs io wait».
Ситуация была в чём… были 2 sata десктопных диска, они были организованы в zfs зеркало без L2ARC и ZIL. При запуске деятельности ВМ на этом массиве фризились и ВМ и гипервизор даже в консоли. Как результат — фризы и огромный io wait.
Переконфигурил в mdadm + lvm — ВМ работают до сих пор без проблем на том первом сервере. Потом был организован второй, где я курил гугл месяц (чистый месяц, вообще больше конечно раза в 3) и выяснял и про HBA и про очереди, тестил на разных очередях и конфигурациях, но всё равно я не добился ничего адекватного даже с ARC, L2ARC и ZIL на простых SSD.
Заработало это нормально когда пришли 3,5 SAS NL 6TB 72 за 14 рублей каждый.
По части Spec vdev. То есть если у меня два PCI-E m2 SSD по 128G, они разбиты по 16 для ZIL в зеркале и 112 в страйпе для L2ARC, то имеет смысл убрать L2ARC, переделать раздел со 112 из страйпа в зеркало и разместить там special vdev? Или лучше оставить L2ARC а в качестве spec dev поставить ещё диск.
Ну… Про ECC прям МИФ. Вообще про zfs разные люди говорят совершенно разные вещи. Я уже чёрти сколько прогуглил, так и не выяснил почему увеличиваются io wait чёрти до скольки и в связи с этим появляются фризы на всех ВМ вместе с гипервизором. У меня проблема не исчезла пока я не поставил SAS диски. У меня не такой уж большой выбор к покупке в связи с бюджетом. Все мои железяки куплены на лично мои денежки, а я не так уж и богат. Есть в наличии SAS NL — взял его, до него стояли SATA диски, показавшие себя неплохо mdadm, но ZFS с ними просто коловая. Почему? Для себя объяснил пока это другим механизмом очереди, и тем, что CoW — это для больших мальчиков с нормальным железом и с другим его количеством. Был потрачено в чистом виде где-то месяц времени на шевеление zfs с SATA. Если у вас так много опыта в этом вопросе вы можете собрать это в компендий, чем много кому поможете. Информацию приходится собирать по крупицам в частности из таких вот комментариев.
Вообще мне больше нравятся производные от зеркал и страйпов конфигурации, но вот сейчас придётся собирать массив из 6-ти 600-х SAS. Другого ничего не будет и 1,8T будет недостаточно, придётся собирать RAID 5 из 3-х пар страйпов. Да, плохо, денег нет, но вы держитесь. Буду набивать опыт, куда без этого, классно это делать за чужие бабки, но мы не ищем лёгких путей.
По части пункта 6… И...? Не стоит его ставить?
special VDEV — отличная наводка, спасибо. Русскоязычной информации по поводу того, как это использовать — не нашёл. Нужно время чтобы перевести и понять что пишут иностранцы. Что с ним делать то, если вкратце? Выкинуть L2ARC и использовать его?
Intel Optane стоил тогда, когда закупалось железо — космоденег. Я нищеброд, поэтому зажал денежку. В нашем DNS тогда продавались на 16 и на 32 m2 платы, по скоростям ввода вывода новый самсунг сильно выигрывал, хотя и известно, что так их сравнивать нельзя. По intel optane было много прочитано, но этого оказалось недостаточно для его покупки.
Вообще как я понял Optane бывают сильно разные и однозначного представления о том, что лучше брать для SLOG — нет. Скиньте статью, если есть чем поделиться о том, что лучше брать для SLOG.
Да, согласен. Sanoid не использовал, но похоже, буду. Спасибо за полезное название. Ну а в целом — в моём скрипте основных 2 команды, за счет простоты можно всегда понять в чём проблема. Swaks прям так плох? Чем вы отправляете? mail? Мне надо чтобы отправлялка могла авторизоваться по логину и паролю на произвольном почтовом сервере.
Нельзя кусать руку, которая кормит. Опенсорс - это достояние человечества. Опенсорс - это общественная собственность на средства производства. Тех, кто участвует в ОПП надо носить на руках, а не персты всякие являть их взору.
Проблема как раз в том, что команда небольшая. Пусть команда будет одна(или несколько под одним началом), но большая и подготовленная государством (со школы). Тогда результат станет сопоставим с Debian, возможно даже станет круче, если будет бесплатным в т.ч. для коммерческого пользования. Не будет малый бизнес покупать Linux, как и не покупал Винду. Будут использовать на свой страх и риск бесплатное. И если в один прекрасный день сработают заплатки и бесплатное остановится, то такая ситуация будет проблемой государственного масштаба (так как произойдёт это, скорее всего в рамках государства по географическому признаку).
P.S. Командам инженеров, которые тянут эту лямку - бесконечный респект. Возможно, им нужна помощь в виде квалифицированных кадров, или хотя бы надежды на то, что эти кадры когда-нибудь появятся в промышленных масштабах.
Было бы бесплатным для коммерции - выбрал бы Alt. Хотя Fly на Астре мне тоже оч понравился. За неимением кед, я бы пользовался. Астра запустилась на моём планшето-ноуте lenovo и без плясок работала с сенсорным экраном (почти) а это пока не удавалось ничему, кроме убунты точ. Но убунта это не моё, как и юнити. Гном - тоже не моё.
Берите! Горя знать не будете!
Увы, мистер Рокфеллер, так тоже не всегда получается. Сейчас именитые производители валят из России и отказывают в поддержке ранее проданных продуктов. То есть вы и цену высокую заплатили и рыбку, так сказать, не съели.
Ну или исходя из такой философии рекомендую купить Rand Rover в повседневное пользование. Дорогой - значит качественный ;)
Да и с тушёнкой такой подход не всегда имеет место быть.
Не понял, как написанное вами соотносится с написанным мной. Я писал про выбор дистрибутива Linux, а не про то, что от него надо отказываться.
Спасибо за пост!
Выбирая из российских дистрибутивов и импортозамещающего софта, приходят те же мысли что и при выборе тушёнки в супермаркете. Каждый раз я трачу кучу времени, читаю что написано на банке, трясу и т.д. и в итоге, как правило, ем не то, что ожидал. Если бы в магазине была бы одна марка тушёнки, но она была бы добротной, то меня бы этот вариант устроил бы больше, чем её ассортимент. На каждой баночке своя наклеечка, у каждого свой директор, некоторые производители даже тратятся на рекламу. То есть деньги тратятся не на качество самого продукта, а на что-то для меня вторичное. Я не за наклейками прихожу в магазин, и не за тем, чтобы трясти банки, а за тушёнкой.
Так же и с дистрибутивами. Чтобы что-то там гарантировать гос. корпорациям, надо осуществлять аудит кода перед компиляцией пакетов. Какая частная лавка потянет такой объём работ на постоянной основе? Где вы возьмёте столько IT-шников (которые будут действительно проверять открытый софт на закладки)? То, что пакеты старые в российских дистрах значит, что конторы их выпускающие не могут позволить себе проверку софта часто. То есть мы будем вынуждены либо пользоваться устаревшими пакетами, либо наращивать штат людей проверяющих код.
Я уверен, что в российских дистрах рекомендуемых в ФСБ, всё-таки проверяют, но получается так, что люди в разных конторах занимаются одним и тем же - проверяют один и тот же открытый софт. В итоге каждый из них изобретает один и тот же велосипед. Если бы они действовали под одним началом, то они могли бы действовать эффективнее.
Это задачи государственного уровня (свой актуальный репозиторий). Пусть дистрибутив будет один, но уделять ему будут бОльшее время. И не надо будет ставить один дистр, щупать, потом другой, щупать, потом возвращаться к первому. Дистрибутив, по сути - набор пакетов. Если изготовитель не может выпускать актуальные пакеты, значит дистрибутив худшего качества, чем западные бесплатные аналоги.
До прочтения этой статьи я планировал попробовать altlinux, а теперь не хочу. Сомнения по поводу переезда на отечественный софт начались после ознакомления с ценами на отечественные продукты. Эта статья подкинула гирьку на весы "остаться на debian". Не будут дискредитировать дебиан для того, чтобы добраться до нас, нищебродов (малый бизнес). Тем, кто вкидывает деньги на заплатки в ОПП, интересна рыбка покрупнее. Гос корпорациям, конечно, надо переходить на своё. А мы, рабы божьи, ставим debian и крестимся двумя руками, уповая на милость заграничных инженеров.
Это я к чему всё это... Чтобы репозиторий был актуальным, надо чаще обновлять пакеты. Чаще обновлять - больше человекочасов, чтобы было откуда взять больше человекочасов, надо больше человек, чтобы было больше человек - их надо больше учить. Учит в промышленных масштабах - только государство. То есть государство должно потратить большее количество денег на обучение, для того, чтобы три (или сколько их там) частных лавочки, получили толковых инженеров и больше стригли денег с пользователей? Государство должно заниматься этим вопросом. Информационная безопасность - стратегическая задача. Бизнес никогда не окупит затрат, которые необходимо потратить на ИБ, достаточную для гос уровня. Спецоперация кончится и по нам будут работать на другом фронте, информационном. Специалисты, которые будут по нам работать - подготовлены вражескими ГОСУДАРСТВАМИ, а не частными конторками. Они пройдут через компетентность специалистов от бизнеса как нож через говно.
Не пробовал. Гугл тоже не в курсе, что за "бинарная репликация postgresql"
Может есть какие-то иные названия?
Нашёл. Это физическая. Да, пробовал. Без неё не знаю как ещё делать почасовые копии. Меня весь этот механизм удручает. А именно держать разные базы в разных службах Postgres для того, чтобы вести почасовые копии какой-то одной базы. Либо все базы будут в твоей копии, либо делай логическую. Я для себя пришёл к выводу, что просто надо заводить несколько постгресов под разные базы, и рисовать какую-то управлялку.
Спасибо. А то собирал скриптами инструмент, который позволяет держать почасовые копии постгри почти так же удобно как MSSQL. Правда под винду. Сейчас запланировал переход на постгри на линуксе, а тот в свою очередь находится на zfs (lxc, чтобы избежать лишних слоёв виртуализации). Снапы поудобнее, чем ловить этот WAL. Попробую, в общем.
Прошу прощения за глупый вопрос. Если снапшотом снимать копию с постгри во время работы - копия будет консистентна? Белые люди так делают?
Я ставил на mdraid сначала. При первом использовании zfs я жидко обосрался, так как при простом зеркале из простых домашних SATA массив просто был никакой. При нагрузке iowait взлетал в небеса и не спускался. Тогда я поставил дебиан на зеркало mdadm стандартным текстовым инсталлером и сверху накатил проксмокс. На mdadm массив заработал, так как и должен был. (система грузилась на обоих дисках по одиночке).
С zfs на стенде что я только не делал, разве что в церковь не ходил. Потратил на него где-то месяца два и так не добился приемлемой производительности. Даже с вынесеными zil и кэшем на ssd. Потом ещё через пол года и год были такие же копания гугла и эксперементов по месяцу где то. Узнал много нового, но ключевое так и не познал, видимо.
Результат дала установка SAS контроллера и самых простых SAS (7200 6Tb) дисков с двумя m2 дисками по 128. M2 разбиты на 100 и 28, 28 в зеркале - zil, 100 кэш на чтение в страйпе.
Массив потянул примерно 25 терминальных рыл, но вешал работу при отправке почасовых снапов на бэкап сервер, от чего пришлось отказаться (оставил только суточные). Мне, кстати, попадался вот такой параметр, который я не пробовал ещё:
zfs_per_txg_dirty_frees_percent = 0
Спустя какое-то время, обнаружил, что утром, люди испытывают дискомфорт. Я опять давай копать везде и накопал zfs_txg_timeout = 15 вместо стандартных 5. В результате утренние просадки ушли. В общем, я посмотрел наверное все маны первых 5-10 страниц по разным запросам, пробовал всё подряд и по отдельности и в комплексе. Пока я не могу похвастаться тем, что я прям уверен, что у меня правильно настроенный массив (скорее всего это далеко не так). Так или иначе такая сборка сейчас почти не порождает io wait в отличие от далее описанного случая. Возможно тут играет роль серверное железо во главе с нормальным SAS контроллером и дисками.
Мне нужен был максимально быстрый массив, но чтобы он был в zfs и зашифрован. Взял два по 128 для системы, два m2(PCI-E4) по 1Tb, два sata SSD по 512.
Первая пара под систему, вторая под массив, третья под вспомогательный массив. Ещё так же был сделан одиночный sata hdd в массив под бекапы.
Железо домашнее, но бодрое (Ryzen 7 5800X). Ну и в итоге даже при копировании с зеркала 1Tb m2 на 512 SSD 1С-ной базы (где-то 50 гиг), iowait увеличивается до 25 и чувствуются лаги, если копировать базу на одиночный HDD то io подрывает до 85, на часик. Второе происходит в нерабочее время, поэтому вопрос остро не стоит. Понятно, конечно, SATA, домашнее железо. Но вот почему с зеркала SSD на зеркало SSD на такой машине io заметно увеличивается и даёт дискомфорт, а тот же mdadm на старом компе, со старыми дисками в зеркале не даёт такой io wait (пусть даже при меньшей скорости записи, но я дискомфорта не чувствую). Иными словами у меня складывается впечатление, что zfs пытается засунуть в блочное устройство данные, со скоростью с которой устройство не справляется. Я писал об этом на форуме проксмокса, и там мне посоветовали ограничить скорость записи на виртуальное устройство в самом проксмоксе, в свойствах ВМ. Ну так себе совет, в общем. Подскажите, знающие товарищи, какие ещё параметры покрутить (предлагайте всё, кроме ashift) буду проверять опять по порядку всё подряд. Проблему надо решать. Вопрос не в том, конечно, почему у zfs высокий iowait а у mdadm + ext4 низкий, а почему он НАСТОЛЬКО высокий, и как бы его сделать ниже.
Но с zfs я уже не слезу. Я не знаю с помощью чего ещё нативно можно держать географически удалённую холодную, зашифрованную, почасовую копию любого по размеру массива.
С btrfs ещё не знаком, если она позволяет тоже самое, что zfs но не подрывает io то хрен с ним пересяду на на неё.
Про mdadm кто-то писал, что не поддерживается. Знаете, когда проксмокс был ещё 5-ым, там в гуях не было и LVM. Это же не значит, что проксмокс его тогда его не поддерживал. Пользуйтесь хоть чем, proxmox в первую очередь debian, а потом уже всё остальное.
Точно, LTSP... Пардон. Я уже давно ковырял тему, только сейчас вспомнил, что меня беспокоило по части клиента. При подключении к виртуалке через spice прокс даёт файл для клиента spice для единоразового доступа (файл после использования трётся). То есть это некий ticket. Я предполагаю, что средствами самого проксмоса и можно насоздавать пользователей, дать права на просмотр своей машины и через api проксмокса получать такие тикеты через какую-нибудь вебку. Вы так и сделали? Может поделитесь основными api запросами? Тема живая и вполне можно её довести до статьи на хабре. Кто-нибудь может новогодние праздники захочет заморочиться.
То есть пользователь с дома зашёл через vpn в офисную сеть(ну или как-то иначе), попал на самодельную вебку (или блин, вообще на сам проксмокс), получил этот файл, запустил его прям из браузера, и вуаля, у пользователя перед носом полноценный рабочий стол со звуком пробросом USB (блэкджеком).
Знающие товарищи, подскажите, можно ли подключиться spice не в виртуальному рабочему столу, а реальному, то есть к тому, который на данный момент выведен на монитор рабочей станции? Можно ли перехватить реальный звук, USB?
Если нельзя... То что уж... Есть X2Go, который точно может(транслировать картинку с монитора), или TurboVNC. Не то пальто, конечно, но что делать.
В общем, если заморачиваться с толстыми клиентами (и к толстым клиентам таки можно подключиться через spice), то должно быть промежуточное звено которое будет знать, где толстый а где виртуалка запущены, и которое будет выдавать файлы для доступа через spice или в проксмокс или к толстому клиенту. Ну а если не заморачиваться, то попробовать сделать на базе api проксмокса. Совсем уж скриптить - лень. И я уже устал поддерживать свои старые рукожопые скрипты десятилетней давности. Когда -то давно было интересно скриптить, сегодня хочется, чтобы было как можно меньше модулей, как работают которые знаю только я (В нашей деревне мало админов работающих с linux).
Без толстых клиентов, наверное на данный момент LTSP+SPICE+PX это самая козырная альтернатива RDP. С толстым клиентом - RDP даже курит.
Где-то год назад пришло озарение, что это, наверное единственная годная альтернатива RDP это и есть Proxmox+Spice+LTSP. Времени на попробовать так и не было. Какой вы использовали клиент (я не про стандартный, а например, который можно запихать в PXE + DHCP)?
Вообще, в офисе можно было бы и не запускать LTSP на гипере. Часть сотрудников, работающих в офисе могут работать на толстых клиентах (у кого железо позволяет). Локально те же кеды будут очень бодры, и полоса пропускания такая не понадобится. Но встаёт вопрос о том, как подключиться к такой машине снаружи, чтобы человек мог зайти в свою терминальную сессию с дома, например. (На данный момент двадцатку лидеров по скачке на sourceforge замыкает TurboVNC, если погуглить, то можно наютубить человека, играющего в какую-то последнюю кваку, через это протокол. Сам - не пробовал. Хотя VNC, конечно не прокинет ни смарткарту, ни принтер, но как простое решение вполне сойдет. Ну или подключиться к локально запущенной Xorg или Wayland через spice. Тоже не знаю, можно ли. Если можно, и прокидываются usb и звук то круто - это оно и есть, терминальное решение, даже круче, чем на базе RDP (за счет толстых клиентов).
Если клиент тонкий, и рабочее место крутится на proxmox, тогда проблем нет - всё централизовано, и всегда мы знаем куда подключаться - на центральный VDI. Но в этом случае не используется возможность запуска LTSP в режиме толстого клиента, в котором не гоняется по сети растровая картинка. Не говоря о том, что тонкие клиенты - это нередко просто старые машины, и некоторые из них вполне ничего и вполне потянут KDE Plasma.
Мой парк тонких клиентах крутится на WTware (Windpows server + RDP). Очень удобно, но хочется Linux на клиентах, полностью opensource решение. 95% моего парка тонких клиентов +/- годные компы и рухлядь, способная отражать картинку на мониторе, два RaspBerry Pi3 B+
На момент установки, самый дешёвый вариант тонкой станции - это Raspberry 3, тогда она стоила 5тыр, а сейчас 10. Столько же, сколько и Rasp 4. Получается самый оптимальный тонкий клиент теперь Raspberry 4(? втварь, вроде ничего, кроме малины, не поддерживает). Вроде как пахнет виндой на arm (или я уже отстал?). В общем варианты есть. Если использовать Raspberry 4, то Plasma на ней будут летать, вместе с 1С, офисом и хромом и 4-х Gb памяти для большинства пользователей - достаточно.
В каждой шутке есть доля шутки... (Я знаю, что VDI это не то пальто, просто идея пришла в голову, вдруг выстрелит).
Извините за сумбурность. Просто очень интересна эта тема, и перекапываю гугл примерно раз в пол года по ней. Очень мало информации. Поэтому спасибо, что поделились реальными данными в части количества машин и полосы пропускания.
Времени на скрипты почти нет. Да и поддержка таких нововведений может сорвать другие работы. Поэтому жду решения из коробки и в редкие часы досуга, пробую всякие spice, x2go и т.д. Пока ближе всех конечно же spice. X2Go - это прям разочарование, даже с KDrive - шляпа.
Deskpool ещё не смотрел, думаю в НГ каникулы поиграться. Предварительно понял только, что бесплатно там что-то только в отношении RDP, будет ли там хорошо работать удалённая убунта (через RDP?) есть сомнения.
Если с помощью spice можно подключиться не к виртуальной машине, а к реальной, пробросив звук и USB, то можно сказать что это будет самое интересное решение по VDI (смесь толстых и тонких клиентов, с возможностью подключаться к толстым клиентам снаружи). Есть люди у которых есть в офисе рабочая станция, а есть те, которые работают из дома. Первым нужны ресурсы proxmox, а вторым - нет. У нас в организации, например перевод на толстые клиенты почти полностью бы разгрузил терминальную машину, и убрал бы нагрузку на локальную сеть.
Вот ещё неплохой красавчик, если кому надо, но уже он как-то неприлично дорого стоит. (Стоил 1200 где-то)
Есть ещё snapzend, но sanoid пока нравится больше.
P.S. По поводу UTC — допёр.
В /lib/systemd/system/sanoid*.service нужно убрать Environment=TZ=UTC
и там и там 7200. Контроллер… ну на mdadm тот же контроллер и был. Можете погуглить «zfs io wait».
Ситуация была в чём… были 2 sata десктопных диска, они были организованы в zfs зеркало без L2ARC и ZIL. При запуске деятельности ВМ на этом массиве фризились и ВМ и гипервизор даже в консоли. Как результат — фризы и огромный io wait.
Переконфигурил в mdadm + lvm — ВМ работают до сих пор без проблем на том первом сервере. Потом был организован второй, где я курил гугл месяц (чистый месяц, вообще больше конечно раза в 3) и выяснял и про HBA и про очереди, тестил на разных очередях и конфигурациях, но всё равно я не добился ничего адекватного даже с ARC, L2ARC и ZIL на простых SSD.
Заработало это нормально когда пришли 3,5 SAS NL 6TB 72 за 14 рублей каждый.
По части Spec vdev. То есть если у меня два PCI-E m2 SSD по 128G, они разбиты по 16 для ZIL в зеркале и 112 в страйпе для L2ARC, то имеет смысл убрать L2ARC, переделать раздел со 112 из страйпа в зеркало и разместить там special vdev? Или лучше оставить L2ARC а в качестве spec dev поставить ещё диск.
Вообще мне больше нравятся производные от зеркал и страйпов конфигурации, но вот сейчас придётся собирать массив из 6-ти 600-х SAS. Другого ничего не будет и 1,8T будет недостаточно, придётся собирать RAID 5 из 3-х пар страйпов. Да, плохо, денег нет, но вы держитесь. Буду набивать опыт, куда без этого, классно это делать за чужие бабки, но мы не ищем лёгких путей.
По части пункта 6… И...? Не стоит его ставить?
special VDEV — отличная наводка, спасибо. Русскоязычной информации по поводу того, как это использовать — не нашёл. Нужно время чтобы перевести и понять что пишут иностранцы. Что с ним делать то, если вкратце? Выкинуть L2ARC и использовать его?
Вообще как я понял Optane бывают сильно разные и однозначного представления о том, что лучше брать для SLOG — нет. Скиньте статью, если есть чем поделиться о том, что лучше брать для SLOG.