Не понимаю, почему вы упорно сравниваете Ext4 без дедупликации и компрессии с ZFS где они включены? В конце-концов они в ZFS даже в дефолтном состояние отключены. И учитывая, что данные в БД в целом и так сами по себе довольно фрагментированы, относительно запросов к ним, то COW далеко не так страшен. Особенно, если вы адаптируете размеры блоков ФС к блокам БД или наоборот.
Насчёт softraid5 — размер блока у ZFS по умолчанию 128Кб, у softraid5, если не ошибаюсь 32Кб. При случайной записи ZFS будет ~4 раза медленней просто из-за отсутствия адаптации к рабочей нагрузке, без относительно её собственных характеристик. Выше, вы кстати жаловались на рост латентности в 4 раза. У большинства аппаратных RAID дефолтный размер stripe блока тоже 32 Кб.
Если что, то на серверах СУБД у нас XFS и я не агитирую там использовать ZFS, но сравнение у вас действительно некорректно.
Вы сравнивали не Ext4 и ZFS, а RAID контроллер в котором аппаратно рассчитывается разбиение блоков на RAID-5 против той же задачи средствами центрального процессора для ZFS. Закономерно, это увеличивает нагрузку на процессор (кто-то же должен считать) и уменьшило отклик (безотносительно каких-либо метаданных). Отдельно напишу — я не считаю ZFS в общем случае значимо производителей, её функциональность имеет свою цену, однако полагать, что её использование даёт 4-х кратное падание отклика неверно.
Но даже это не отменяет мой комментарий, относительно вклада файловой системы, выигрыш от замены RAID-5 на RAID-10 будет существенней, чем от замены файловой системы. Для меня даже как-то дико, что кто-то держит базу на 5-м, учитывая вполне осязаемый риск вылета второго HDD раньше окончания перестроения тома и не очень высокую скорость.
В Oracle Linux XFS, потому как они делают RedHat-base дистрибутив. А у Red Hat-а XFS по причинам описанным в статье: How to Choose Your Red Hat Enterprise Linux File System там же сценарии, в которых она лучше/хуже Ext4.
Для Oracle родная как раз Btrfs, они её стартовали как альтернативу ZFS ещё до покупки Sun. А после покупки, и до сих пор вроде не спешат делать двойную лицензию для ZFS, что бы получить совместимость с GPL и возможность включения в ядро.
Насчёт PostgreSQL — база данных не бенчмарк, основные операции чтение/запись блоков в существующих файлах, поэтому, в общем случае прямо какой-то невероятной разницы между разными файловыми системами не будет. Возможно даже наоборот, отсутствие сжатие уменьшит TPS.
DMDM у оператор связи решает вопрос пропускной способности, а не числа вложенных сетей. Ваш тезис насчет Ethernet/FiberChannel не даёт ответа на этот вопрос. Если так хочется провайдерское решение, можно было позаботиться об MPLS, это дало бы и большую надёжность, и относительную независимость от вендора и Ethernet-ы можно было бы в линк пихать не десятками а сотнями тысяч. А стоит меньше. Ну и, как правило, корректней L2 бить на подсети — проблем меньше. Не говоря про разновидности VLAN и VPN, потому как передавать нешифрованные данные по Fiber Channel на десятки км — так себе затея. А он вроде только как интерфейс к СХД и остался…
Насчёт целей статьи — вырисовывается только маркетинговая. Но менеджмент не разбирающийся в технических деталях не будет её здесь читать. А специалисты разбирающиеся, пропустят её как воду.
Хорошо, что не оспариваете ложность тезиса штучной поставки DWDM оборудования. Если вам не требуется 80+ км расстояние и 40+ каналов в одном линке — то оптические трансиверы и мультиплексоры можно сейчас хоть онлайн заказать, в распространённых маркетплейсах. Насчёт необходимости спаять… я надеюсь вы понимаете каким образом делают непрерывное оптическое волокно между приёмником и передатчиком?
Готовность вендора работать — это очень хорошо. Учитывая что Huawei на сложных внедрениях свое оборудование ещё и допиливает в виду вываливающихся из него багов — для Huawei это тоже хорошо. Но чем совершенней будет их оборудование, тем ближе они будут к позиции той же Cisco, которой всё безразлично — и тогда, отсутствие собственных способностей будет очень сильно бить.
Да, наверное наверное и так можно воспринять мой комментарий. Но имелось в виду, что выбор включает в себя не только использование RAID или CoW файловой системой, но и возможность скомбинировать их для некоторых сценариев.
При этом, в целом, я в большей степени сторонник наличия резервного копирование данных. Т.е. в ситуациях серьезных сбоев (если это что-то больше горячей замены диска) вы не занимаетесь починкой массива, или файловой системы, а просто пересоздаёте их и развертываете одну из резервных копий. К сожалению, даже CoW ФС можно ввести в полностью не поддерживаемое состояние, когда извлечь с них данные оказывается крайне затруднительно.
Ну а насчёт тормозов и хая — он в значительной мере вызван тем, что функционал не подкреплен адекватными инструментами диагностики и простым описанием последствий для производительности. И пытаясь использовать сложную комбинацию разных функций (а сами ФС это скорей поощряют) можно иногда получить падение производительности в совершенно неожидаемых масштабах.
Почему? Вы задумывались, что стоит за этой фразой?
ZFS не рекомендуют использовать поверх RAID, из-за того, что это нивелирует многочисленные технические ухищрения в ней, направленные на борьбу с ошибками, в том числе аппаратного характера. Из-за того, что выход из строя аппаратного контроллера, в некоторых, редких сценариях может разрушить массив. Из-за большей гибкости в управлении томами, которую может давать ZFS для сложных сценариев.
И всё это никак не соотносятся с другими функциями ZFS, вроде снимков состояния или сжатия.
При этом ZFS в режиме JBOD будет существенно медленней, чем обычный RAID контроллер, с батарейкой, Write-Back и осознанием рисков такого сценария. Или можно функциональностью ZFS дополнить дисковую полку, в которой в принципе нет режима JBOD — и это тоже будет быстрей, чем делать по отдельному LUN на каждый диск. Поэтому нет ничего зазорного, в том, что бы делать пул поверх RAID, если вы понимаете, что при этом теряете и что приобретаете, а не слепо следуете какой-либо книге.
Btrfs создавалась как альтернатива ZFS, поэтому, в целом, их принципы и функциональные возможности идентичны. Учитывая богатство этих возможностей, обычно, используют только одну из этих файловых систем. Из-за чего объективное сравнение опыта использования в идентичных условиях — редкость, а в таких статьях упор делается только на одну из них.
Если не секрет, поделитесь в комментарии или статье причинами подтолкнувшими к dattobd и опытом работы с ним?
Отвечу за автора статьи: zfs ортогональна аппаратному RAID.
У ZFS есть две киллер-фичи для резервного копирования:
1. Дешевые снимки состояния, с возможностью доступа во внутрь. Вы можете делать checkpoint-ы тысячами, без какого-либо влияния на производительность. Можете их сотнями одномоментно удалять, не заметно для текущих операций чтения/записи.Можете зайти в каталог .zfs/snapshots/имя-снимка и получить копию файловой системы этого снимка.
2. Возможность репликации снимков по сети.
Обычные RAID контроллеры, да и дисковые массивы начального-среднего ценового уровня такого не умеют. Поэтому, нет ничего зазорного в том, чтобы собрать RAID массив с помощью контроллера (ради скорости) и сделать на нём файловой системой ZFS (ради снимков и репликации), решая каждым элементом свою задачу. Естественно возможностей у ZFS сильно больше, но в контексте резервного копирования важны эти две.
ИМХО, «деструктивная» и «нормальная» — это оценочные суждения. Для вас человек «деструктивный», для его руководителя «нормальный», для другого коллеги «ты лучший!».
И нельзя работать «для компании» — компания это не личность, у неё нет целей и интересов. Цели и интересы есть у владельцев компании, у каждого из сотрудников. Причем уже просто от наличия нескольких владельцев у них могут быть противоположные цели, не говоря про менеджмент разного уровня. «Работа для компании» рядового сотрудника — это в значительной мере перекладывание ответственности всех вышележащих руководителей. В идеальной ситуации, именно они должны организовать работу так, что бы она совпадала с целями и задачами, которые мажоритарный владелец ставит.
Поэтому я и хочу акцентировать внимание, что для возникновения описываемой вами ситуации с «деструктивной звездой» недостаточно одного человека. Это в значительной мере плод трудов многих людей. И кадровая ротация «крайнего» глобально положительных последствий не принесёт.
Короля делает свита — в другом коллективе ваша «звезда» легко может быть середнячком или ниже среднего. И вместо того, что бы повышать квалификацию имеющихся у вас сотрудников или нанять ещё нескольких человек по профессиональней, вы предлагаете уволить наиболее квалифицированного человека и взять на его место кого-нибудь по хуже…
Сделайте в своих рассуждениях шаг дальше. Насчёт Bus factor — ну не станет вашей «звезды», если другие сотрудники не тянули эту работу, за счёт чего она выполниться? Просто будет некоторая деградация — вот и всё. А если иные сотрудники тянули эту работу, то как менеджмент допустил сосредоточение всего в одних руках — может дело не в боярах тогда?
PS. Есть действительно люди в себе — очень классные специалисты, но для сохранения своей квалификации им нужны квалифицированные кадры в окружение и они либо подтягивают других, либо через время уходят. А описанное вами… сталкивался и с таким, ваши «звезды» горят потому, что описываемый руководитель:
открывают бутылку дорогого коньяка
вместо того, что бы руководить. И подобные звезды банально выполняют часть обязанностей, в том числе этого руководителя, что сильно влияет на их цели и экспертиза там уже не чисто техническая, а с сильным уклоном в менеджмент. И само по себе это плохо, но кадровая проблема здесь уже не в технических специалистах, а в руководителях.
А зачем DWDM? У магистральных провайдеров — да, проще ценник оконечного оборудования умножить в 5-20 раз и уплотнить канал, чем тянуть трассу. Но финансовой организации зачем DWDM? Почему Huawei OptiX OSN 8800? Ни причин выбора, ни альтернатив… Утверждение
Поставка оборудования DWDM – дело штучное, под заказ
вообще странно выглядит. Лет 15-ть назад вроде в свободной продаже всё было. В целом в статье никаких технических деталей…
Сухой остаток: TAC Huawei сделал часть работы по проектированию/внедрению своего оборудования, спасибо им.
Потому что, пара 911 и 112 и есть мировой стандарт и оба эти номера всегда, в любых ситуациях должны быть доступны. Есть ещё 000, 08, 110, 999, 118 и 119 которые должны работать при отсутствии SIM карты. А при наличии SIM ещё пачка номеров с неё. А при наличии сети оператора ещё пачка актуальных номеров оттуда. Другой вопрос, что обработка 911 и 112, да и экстренные вызовы в целом — это требование к самому телефону, и соответственно находятся недобросовестные производители, которые это требование стандарта не выполняют.
Насчёт обратного звонка без SIM, это моя ошибка, некорректная трактовка текста стандарта — такого нет. По местоположению, при экстренных вызовах оператор может, в зависимости от законодательства страны, добавить в вызов дополнительные поля, со сведениями о местоположении абонента — но в стандарте очень чётко прописано, что такое происходит только для вызовов идентифицируемых как экстренные и инициировать со стороны сервера это нельзя. Предполагается, что это конфиденциальные данные, которые могут быть получены у оператора только по запросу правоохранительных органов, если их сбор в принципе разрешен законодательством страны.
Сыплю голову пеплом, вечер пятницы, та часть спецификаций с которыми особо не приходится работать и несколько не так в итоге трактовал текст. Поддержка обратного вызова при ограниченном обслуживании (в том числе без sim) не требуется. К такому обратному вызову в целом нет каких-то совсем особых требований — он проходит как обычный звонок и оператор даже не обязан его как-то идентифицировать. По поводу остального, описание принципов есть в 3GPP TS 22.101 раздел «Emergency Calls».
Прослойка взялась из стандартов. «категория emergency» это некоторое упрощение. На самом деле это приличных кусок спецификаций, описывающий, что в телефоне и sim карте прошиваются номера экстренных служб, они актуализируются домашним оператором при наличии сети, возможность вызова без sim, совершение звонков без набора номера (например автоматом при срабатывании подушек безопасности автомобиля), приоритет таких звонков над всеми остальными, возможность обратного вызова (перезвонят на телефон без SIM карты), передача вместе с вызовом доп данных, вроде GPS. В корректно настроенной сети, если обычному звонку «присвоить этот флаг», то он будет переадресован в местную службу спасения, вне зависимости от номера, который был набран.
В разных странах разные номера экстренных служб и владелец телефона не должен умереть просто из-за незнания номера, даже если окажется в незнакомой стране. Поэтому, к примеру, вы с Японской симкой, совершая звонок в России попадете в службу спасения набрав 110, 118 или 119. И даже без SIM, кроме 112 и 911, ещё несколько номеров, вроде 000 должны переадресовываться в службу спасения.
А сам по себе именно флаг нужен, что бы маркировать звонки которые базовые станции должны обслуживать без SIM и которым должны отдавать приоритет канальной емкости над всем остальным (упрощенно слоты радиоканала под вызов выделяется до получения от телефона номера звонка).
Ссылка на статью «от 26 января 2016 г.» с тем же содержанием про «98%» есть, а вот, собственно списка проверенных сайтов и нет… А ведь за 4,5 года что-то и поменяться могло.
А чем не устраивает «ssh -XC»? Никаких проблем ни со шрифтами, ни со скоростью не наблюдаю.
IDEA или Firefox целиком рендерят свои окна и попытки пробросить с Linux на Windows их через SSH X11 Forwading приводят к совершенно фантастическим тормозам (20-30-40 секунд открытие пункта меню, например), даже если они запущены в виртуальной машине на том же компьютере или на сервере через один коммутатор.
Возможно просто в вашей организации некомпетентные юристы. Я сужу об этом по:
оформили передачу прав от физика к юрику
По отечественному законодательству, действительно, неимущественные права (возможность называться автором) могут принадлежать только физическому лицу. Юрику могут принадлежать только имущественные права (грубо говоря, торговать этим по). Под регистрацией прав на систему, если я верно понимаю, имеется в виду регистрация в Роспатенте. И если делать правильно, то там, в документах указывается: авторы такие-то физические люди, правообладатель такое-то юридическое лицо, основание правообладания — работодатель авторов. И нет никаких правовых коллизий. Отсутствуют покупки или передачи прав — есть только фиксация того факта, что права принадлежат юрлицу, а саму программу сделали такие-то сотрудники этого юрлица. А делать вариант, с передачей прав собственности от собственных сотрудников, вместо приобретения этих прав в качестве работодателя, это чрезвычайно сомнительная правовая процедура со всех точек зрения.
Наверное пример просто не удачный. Mobile IP в добавок к тому что вы описываете, предполагает такое же поведение и при роуминге в сети другого оператора, который отправит ваш трафик в ваш домашний регион. И при переключении просто в другую сеть, например к домашнему WiFi, когда трафик из него улетит не в живую в сеть, а опять же сначала в сеть оператора. Это опять же сильно утрированно.
А то что вы описали, связанно всё же не с особенностями 2G/3G/4G, а с работой конкретного оператора. Может им было так проще сделать для горячего биллинга, как выше написал wlr398. Может это специфика их пиринга с другими операторами. Но это не особенность сетей сотовой связи, связанная с их архитектурой или какими-то требованиями/спецификациями. Это то, то как конкретный оператор настроил свои сети.
Mobile IP есть и для IPv4, его идея в сохранении внешнего адреса (v4 или v6) выделенного устройству. Предполагается, что телефон (девайс) сохраняет его выделенные ему адрес при попадании в роуминг другого оператора или перемещаясь на другой конец земли или меняя тип подключения.
С одной стороны это даёт возможность иметь фиксированный внешний адрес, что особенно актуально для IPv6 и VoIP, можно менять тип доступа в сеть, переключать между 3G и WiFi например — а всё соединения остаются работать. С другой стороны, для этого трафик перенаправляется всё на тот же шлюз доступа. Т.е., условно, вы например абонент московского сотового оператора приехали во Владивосток и хотите зайти на городской сайт, хостящейся во Владивостоке же. Без Mobile IP шлюз доступа где-то на дальнем востоке получит трафик от вас и завернет его в интернет, и в идеале, всё будет циркулировать внутри дальневосточного региона, с минимальным пингом. Благодаря Mobile IP, ваш трафик будет ретранслирован в Москву, к вашему домашнему шлюзу доступа в сеть и уже от туда вернётся во Владивосток, увеличивая пинг, но сохраняя московский IP.
По сути Mobile IPv6 создан, чтобы снять с разработчиков приложений головную боль по переподключению при смене внешнего адреса, но это не связано с какими-то прямо принципиальными отличиями применения IPv6 от IPv4 в мобильных сетях.
Насчёт softraid5 — размер блока у ZFS по умолчанию 128Кб, у softraid5, если не ошибаюсь 32Кб. При случайной записи ZFS будет ~4 раза медленней просто из-за отсутствия адаптации к рабочей нагрузке, без относительно её собственных характеристик. Выше, вы кстати жаловались на рост латентности в 4 раза. У большинства аппаратных RAID дефолтный размер stripe блока тоже 32 Кб.
Если что, то на серверах СУБД у нас XFS и я не агитирую там использовать ZFS, но сравнение у вас действительно некорректно.
Но даже это не отменяет мой комментарий, относительно вклада файловой системы, выигрыш от замены RAID-5 на RAID-10 будет существенней, чем от замены файловой системы. Для меня даже как-то дико, что кто-то держит базу на 5-м, учитывая вполне осязаемый риск вылета второго HDD раньше окончания перестроения тома и не очень высокую скорость.
Для Oracle родная как раз Btrfs, они её стартовали как альтернативу ZFS ещё до покупки Sun. А после покупки, и до сих пор вроде не спешат делать двойную лицензию для ZFS, что бы получить совместимость с GPL и возможность включения в ядро.
Насчёт PostgreSQL — база данных не бенчмарк, основные операции чтение/запись блоков в существующих файлах, поэтому, в общем случае прямо какой-то невероятной разницы между разными файловыми системами не будет. Возможно даже наоборот, отсутствие сжатие уменьшит TPS.
Насчёт целей статьи — вырисовывается только маркетинговая. Но менеджмент не разбирающийся в технических деталях не будет её здесь читать. А специалисты разбирающиеся, пропустят её как воду.
Хорошо, что не оспариваете ложность тезиса штучной поставки DWDM оборудования. Если вам не требуется 80+ км расстояние и 40+ каналов в одном линке — то оптические трансиверы и мультиплексоры можно сейчас хоть онлайн заказать, в распространённых маркетплейсах. Насчёт необходимости спаять… я надеюсь вы понимаете каким образом делают непрерывное оптическое волокно между приёмником и передатчиком?
Готовность вендора работать — это очень хорошо. Учитывая что Huawei на сложных внедрениях свое оборудование ещё и допиливает в виду вываливающихся из него багов — для Huawei это тоже хорошо. Но чем совершенней будет их оборудование, тем ближе они будут к позиции той же Cisco, которой всё безразлично — и тогда, отсутствие собственных способностей будет очень сильно бить.
При этом, в целом, я в большей степени сторонник наличия резервного копирование данных. Т.е. в ситуациях серьезных сбоев (если это что-то больше горячей замены диска) вы не занимаетесь починкой массива, или файловой системы, а просто пересоздаёте их и развертываете одну из резервных копий. К сожалению, даже CoW ФС можно ввести в полностью не поддерживаемое состояние, когда извлечь с них данные оказывается крайне затруднительно.
Ну а насчёт тормозов и хая — он в значительной мере вызван тем, что функционал не подкреплен адекватными инструментами диагностики и простым описанием последствий для производительности. И пытаясь использовать сложную комбинацию разных функций (а сами ФС это скорей поощряют) можно иногда получить падение производительности в совершенно неожидаемых масштабах.
ZFS не рекомендуют использовать поверх RAID, из-за того, что это нивелирует многочисленные технические ухищрения в ней, направленные на борьбу с ошибками, в том числе аппаратного характера. Из-за того, что выход из строя аппаратного контроллера, в некоторых, редких сценариях может разрушить массив. Из-за большей гибкости в управлении томами, которую может давать ZFS для сложных сценариев.
И всё это никак не соотносятся с другими функциями ZFS, вроде снимков состояния или сжатия.
При этом ZFS в режиме JBOD будет существенно медленней, чем обычный RAID контроллер, с батарейкой, Write-Back и осознанием рисков такого сценария. Или можно функциональностью ZFS дополнить дисковую полку, в которой в принципе нет режима JBOD — и это тоже будет быстрей, чем делать по отдельному LUN на каждый диск. Поэтому нет ничего зазорного, в том, что бы делать пул поверх RAID, если вы понимаете, что при этом теряете и что приобретаете, а не слепо следуете какой-либо книге.
Если не секрет, поделитесь в комментарии или статье причинами подтолкнувшими к dattobd и опытом работы с ним?
У ZFS есть две киллер-фичи для резервного копирования:
1. Дешевые снимки состояния, с возможностью доступа во внутрь. Вы можете делать checkpoint-ы тысячами, без какого-либо влияния на производительность. Можете их сотнями одномоментно удалять, не заметно для текущих операций чтения/записи.Можете зайти в каталог .zfs/snapshots/имя-снимка и получить копию файловой системы этого снимка.
2. Возможность репликации снимков по сети.
Обычные RAID контроллеры, да и дисковые массивы начального-среднего ценового уровня такого не умеют. Поэтому, нет ничего зазорного в том, чтобы собрать RAID массив с помощью контроллера (ради скорости) и сделать на нём файловой системой ZFS (ради снимков и репликации), решая каждым элементом свою задачу. Естественно возможностей у ZFS сильно больше, но в контексте резервного копирования важны эти две.
И нельзя работать «для компании» — компания это не личность, у неё нет целей и интересов. Цели и интересы есть у владельцев компании, у каждого из сотрудников. Причем уже просто от наличия нескольких владельцев у них могут быть противоположные цели, не говоря про менеджмент разного уровня. «Работа для компании» рядового сотрудника — это в значительной мере перекладывание ответственности всех вышележащих руководителей. В идеальной ситуации, именно они должны организовать работу так, что бы она совпадала с целями и задачами, которые мажоритарный владелец ставит.
Поэтому я и хочу акцентировать внимание, что для возникновения описываемой вами ситуации с «деструктивной звездой» недостаточно одного человека. Это в значительной мере плод трудов многих людей. И кадровая ротация «крайнего» глобально положительных последствий не принесёт.
Сделайте в своих рассуждениях шаг дальше. Насчёт Bus factor — ну не станет вашей «звезды», если другие сотрудники не тянули эту работу, за счёт чего она выполниться? Просто будет некоторая деградация — вот и всё. А если иные сотрудники тянули эту работу, то как менеджмент допустил сосредоточение всего в одних руках — может дело не в боярах тогда?
PS. Есть действительно люди в себе — очень классные специалисты, но для сохранения своей квалификации им нужны квалифицированные кадры в окружение и они либо подтягивают других, либо через время уходят. А описанное вами… сталкивался и с таким, ваши «звезды» горят потому, что описываемый руководитель:
вместо того, что бы руководить. И подобные звезды банально выполняют часть обязанностей, в том числе этого руководителя, что сильно влияет на их цели и экспертиза там уже не чисто техническая, а с сильным уклоном в менеджмент. И само по себе это плохо, но кадровая проблема здесь уже не в технических специалистах, а в руководителях.
Сухой остаток: TAC Huawei сделал часть работы по проектированию/внедрению своего оборудования, спасибо им.
В разных странах разные номера экстренных служб и владелец телефона не должен умереть просто из-за незнания номера, даже если окажется в незнакомой стране. Поэтому, к примеру, вы с Японской симкой, совершая звонок в России попадете в службу спасения набрав 110, 118 или 119. И даже без SIM, кроме 112 и 911, ещё несколько номеров, вроде 000 должны переадресовываться в службу спасения.
А сам по себе именно флаг нужен, что бы маркировать звонки которые базовые станции должны обслуживать без SIM и которым должны отдавать приоритет канальной емкости над всем остальным (упрощенно слоты радиоканала под вызов выделяется до получения от телефона номера звонка).
IDEA или Firefox целиком рендерят свои окна и попытки пробросить с Linux на Windows их через SSH X11 Forwading приводят к совершенно фантастическим тормозам (20-30-40 секунд открытие пункта меню, например), даже если они запущены в виртуальной машине на том же компьютере или на сервере через один коммутатор.
По отечественному законодательству, действительно, неимущественные права (возможность называться автором) могут принадлежать только физическому лицу. Юрику могут принадлежать только имущественные права (грубо говоря, торговать этим по). Под регистрацией прав на систему, если я верно понимаю, имеется в виду регистрация в Роспатенте. И если делать правильно, то там, в документах указывается: авторы такие-то физические люди, правообладатель такое-то юридическое лицо, основание правообладания — работодатель авторов. И нет никаких правовых коллизий. Отсутствуют покупки или передачи прав — есть только фиксация того факта, что права принадлежат юрлицу, а саму программу сделали такие-то сотрудники этого юрлица. А делать вариант, с передачей прав собственности от собственных сотрудников, вместо приобретения этих прав в качестве работодателя, это чрезвычайно сомнительная правовая процедура со всех точек зрения.
А то что вы описали, связанно всё же не с особенностями 2G/3G/4G, а с работой конкретного оператора. Может им было так проще сделать для горячего биллинга, как выше написал wlr398. Может это специфика их пиринга с другими операторами. Но это не особенность сетей сотовой связи, связанная с их архитектурой или какими-то требованиями/спецификациями. Это то, то как конкретный оператор настроил свои сети.
С одной стороны это даёт возможность иметь фиксированный внешний адрес, что особенно актуально для IPv6 и VoIP, можно менять тип доступа в сеть, переключать между 3G и WiFi например — а всё соединения остаются работать. С другой стороны, для этого трафик перенаправляется всё на тот же шлюз доступа. Т.е., условно, вы например абонент московского сотового оператора приехали во Владивосток и хотите зайти на городской сайт, хостящейся во Владивостоке же. Без Mobile IP шлюз доступа где-то на дальнем востоке получит трафик от вас и завернет его в интернет, и в идеале, всё будет циркулировать внутри дальневосточного региона, с минимальным пингом. Благодаря Mobile IP, ваш трафик будет ретранслирован в Москву, к вашему домашнему шлюзу доступа в сеть и уже от туда вернётся во Владивосток, увеличивая пинг, но сохраняя московский IP.
По сути Mobile IPv6 создан, чтобы снять с разработчиков приложений головную боль по переподключению при смене внешнего адреса, но это не связано с какими-то прямо принципиальными отличиями применения IPv6 от IPv4 в мобильных сетях.