Open hredestig opened 5 years ago
I'm having the exact same issue. Have been using dtctester.exe to test MSDTC. So far no luck. I've tried all the configuration options mentioned here in the docs below. According to the docs MSDTC is supported now.
https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-configure-msdtc?view=sql-server-ver15 https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-configure-mssql-conf?view=sql-server-ver15 https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-configure-msdtc-docker?view=sql-server-ver15 I cannot get it working however. I've tried both SQL 2017CU and 2019CU
These seem to be the only documented options to configure:
sudo /opt/mssql/bin/mssql-conf set distributedtransaction.turnoffrpcsecurity 1
sudo /opt/mssql/bin/mssql-conf set distributedtransaction.fallbacktounsecurerpcifnecessary 1
sudo /opt/mssql/bin/mssql-conf set distributedtransaction.allowonlysecurerpccalls 0
sudo /opt/mssql/bin/mssql-conf set network.rpcport 13500
sudo /opt/mssql/bin/mssql-conf set distributedtransaction.servertcpport 51999
dtctester gives me the exact same output as hredestig here above.
Btw, I have MSDTC working fine on a SQL Windows Container, although it took alot of time to get working. It would be great to get this working on linux as well.
I'm also having the same problem someone managed to solve?
I haven't found any solution yet. I'm hoping a M$ rep will see this thread and tell us how MSDTC is supposted to work on linux containers. Seems kind of weird that the official docs from Microsoft claim that MSDTC is fully supported while a basic DTC setup like this is impossible to get working.
Agreed.. I gave up and went for VM based solution :/
Hello there,
Have anyone tried to use the latest image of SQL Server 2019? mcr.microsoft.com/mssql/server:2019-CU3-ubuntu-18.04
I was checking the thread, it is from August 2019. Based on the release cycle, SQL Server 2019 was not GA at that time. I strongly recommend to use the latest image and try again, most of the known issues are fixed in the post GA release through CU's (cumulative updates).
Regards,
Hello there,
Have anyone tried to use the latest image of SQL Server 2019? mcr.microsoft.com/mssql/server:2019-CU3-ubuntu-18.04
I was checking the thread, it is from August 2019. Based on the release cycle, SQL Server 2019 was not GA at that time. I strongly recommend to use the latest image and try again, most of the known issues are fixed in the post GA release through CU's (cumulative updates).
Regards,
No, do not work.
@vin-yu , @kapilth , @rothja as FYI.
Can you please paste your container execution command line? Did you also configure the port forwarding on the host from port 135 to the "defined RPC" port that container is listening on? https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-configure-msdtc?view=sql-server-ver15#configure-port-routing
Additionally, do you have more than one containers trying to listen on RPC port? When you are configuring port forwarding on the host IP port 135 to container's RPC port, only one container can be configured to listen to it. So if you are trying to configure multiple containers for MSDTC, then you'll want to create multiple logical IPs on the host's NIC using nmcli or network manager of your choice. Then you'll want to bind the container logical host name to those logical IPs.
Following is an example configuration for configuring multiple containers to listen to port 135 on a single host with appropriate IP bindings. In this case i have assumed a Linux VM in Azure on which i have added multiple IP addresses, one for each container using following. https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-multiple-ip-addresses-portal
In this example, I am creating two SQL container on Ubuntu host(Azure IaaS VM), which has two additional IP addresses, 172.16.0.15 and 172.16.0.19, one assigned for each SQL container. (Starting RHEL 8, you would use podman instead of docker.)
_docker run \ -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<UseComplexPassword!1234>' \ -e 'MSSQL_RPC_PORT=13500' -e 'MSSQL_DTC_TCP_PORT=51000' \ -p 172.16.0.15:51433:1433 -p 172.16.0.15:13500:13500 -p 172.16.0.15:51000:51000 \ -h SQLContainer1 --name sqlcnt1 \ -d mcr.microsoft.com/mssql/server:2017-latest
docker run \ -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<UseComplexPassword!1234>' \ -e 'MSSQL_RPC_PORT=13500' -e 'MSSQL_DTC_TCPPORT=51000' \ -p 172.16.0.19:51433:1433 -p 172.16.0.19:13500:13500 -p 172.16.0.19:51000:51000 \ -h SQLContainer2 --name sqlcnt2 \ -d mcr.microsoft.com/mssql/server:2017-latest
On the Host server for both containers, execute following to create appropriate port forwarding for appropriately assigned logical Ips to the containers. (On RHEL and starting SLES 15, port forwarding tends be easier to configure with firewall-cmd itself, where you also open the port for communication outside the VM.) _sudo iptables -t nat -A PREROUTING -d 172.16.0.15 -p tcp --dport 135 -m addrtype --dst-type LOCAL \ -j DNAT --to-destination 172.16.0.15:13500 -m comment --comment RpcEndPointMapper1 sudo iptables -t nat -A OUTPUT -d 172.16.0.15 -p tcp --dport 135 -m addrtype --dst-type LOCAL \ -j DNAT --to-destination 172.16.0.15:13500 -m comment --comment RpcEndPointMapper1
sudo iptables -t nat -A PREROUTING -d 172.16.0.19 -p tcp --dport 135 -m addrtype --dst-type LOCAL \ -j DNAT --to-destination 172.16.0.19:13500 -m comment --comment RpcEndPointMapper2 sudo iptables -t nat -A OUTPUT -d 172.16.0.19 -p tcp --dport 135 -m addrtype --dst-type LOCAL \ -j DNAT --to-destination 172.16.0.19:13500 -m comment --comment RpcEndPointMapper2_
(On RHEL, sudo firewall-cmd --permanent --add-forward-port=port=135:proto=tcp:toport=13500 sudo firewall-cmd --reload )
In /etc/hosts of each container, make entry for "HOST" level IP mapped to container name. Alternatively, you can ensure that DNS name resolution between IP and container name works appropriately which would avoid having to modify the /etc/hosts file in the container itself.
In sqlcnt1 /etc/hosts, make a host entry, 172.16.0.19 SQLContainer2 (Requires to open bash via “docker exec -it sqlcnt1 bash” in SQLcnt1 context. Then do apt update and apt install nano. And then use nano editor to modify /etc/hosts file.)
In SQLcnt2 /etc/hosts, make a host entry, 172.16.0.15 SQLContainer1 (Requires to open bash via “docker exec -it sqlcnt2 bash” in SQLcnt2 context. Then do apt update and apt install nano. And then use nano editor to modify /etc/hosts file.)
_USE [master]
GO
EXEC master.dbo.sp_addlinkedserver @server = N'172.16.0.19,51433', @srvproduct=N'SQL Server' ;
GO
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname = N'172.16.0.19,51433', @rmtuser = 'sa', @rmtpassword = '<UseComplexPassword!1234>', @useself = N'False'; GO
set xactabort on begin distributed transaction select * from [172.16.0.19,51433].master.dbo.sysprocesses commit Go
Of course, you'll want to make sure on the host that firewall has appropriate port exceptions enabled. sudo ufw allow from any to any port 51433 proto tcp sudo ufw allow from any to any port 51000 proto tcp sudo ufw allow from any to any port 135 proto tcp
(on RHEL, sudo firewall-cmd --zone=public --add-port=51000/tcp --permanent sudo firewall-cmd --zone=public --add-port=51433/tcp --permanent sudo firewall-cmd --zone=public --add-port=135/tcp --permanent sudo firewall-cmd --reload )
We will try to get some documentation out for such configuration asap.
This problem may be caused by HOSTNAME LOOKUP . Add host entry to /etc/hosts , and everything works
root@4f73454bf03e:/# echo "172.17.0.4 6b7401bc1c5b" >> /etc/hosts
root@6b7401bc1c5b:/# echo "172.17.0.3 4f73454bf03e" >> /etc/hosts
root@4f73454bf03e:/# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.3 4f73454bf03e
172.17.0.4 6b7401bc1c5b
root@4f73454bf03e:/# /opt/mssql-tools/bin/sqlcmd -U sa
Password:
1> BEGIN DISTRIBUTED TRANSACTION
2> SELECT top 1 spid,lastwaittype FROM [172.17.0.4].master.dbo.sysprocesses;
3> COMMIT
4> GO
spid lastwaittype
------ --------------------------------
1 WAIT_XTP_HOST_WAIT
(1 rows affected)
1>
2>
I'll certainly emphasize that the use of containers on VMs should ideally be limited to small dev/test environments as containers are better deployed and managed in Kubernetes environments. For example, compared to the configuration I described in an earlier post, the container with MSDTC configuration enabled can be deployed much easily in K8s environments. Following blog should give some insights into how much easier it can be to enable MSDTC for containers in K8s.
I run docker 18.09.6 on centos 7 and followed the instructions for setting MSDTC capable SQL Server to serve an application that relies on MSDTC. That application cannot connect to my container and fails with message
Container started as expected with logs
To get a more low-level test than the application I actually target, I use dtctester on a windows client directly connected to the server, no intermediate firewall. I can ping in both directions. NetBIOS name resolves as checked by nbtstat on client to server. Output of dtctester is in line with previous error message
I have enterprise Standard SQL Server license but understand that MSDTC on docker is not officially supported yet and that I should post my question here.
Some help / ideas would be most appreciated!